MuleSoft: Tactical and Strategical Role of an Application Template

This story started with a new project when businesses expressed concerns about existing integrations and shared their views and expectations for our future POC (Proof of Concept). The business's main interest revolved around troubleshooting, after-development support, onboarding, and knowledge transfer for future projects. Disappointment with existing Point-to-Point integrations developed by third-party vendors with various technologies, patterns, and approaches was a pain in the neck and a challenge for the volatile business environment.

Our POC aimed to resolve existing pain points and set up a strategic foundation for future implementations, which was supposed to resolve troubleshooting, after-development support, onboarding, and knowledge transfer problems.

I sketched out an initial list of questions our project would address:

• Handle errors and exceptions;
• Manage logs and logging;
• Naming conventions and best practices;
• Shared libraries and functions;
• Requirements for the code review;
• Fast onboarding of new team members;
• Documentation and information sharing among team members.

Usually, a widely-used approach to tackling these questions was writing detailed documentation containing steps, diagrams, references, etc. I desired to avoid that or maybe deter from it at the outset of the project and keep it until the end when our vision becomes clear and mature. A decision was made to leverage an application template for our undertaking, one of the many best practices that MuleSoft offers.

After follow-up meetings with stakeholders, some answers became more apparent to us:

• Logging and error handling must be standardized for easy troubleshooting throughout all applications.
• We need to externalize some code as libraries (plugins) for heartbeat, error handlers, and joint functions. 

I met with the team, and the team agreed to create, maintain, and employ our first application template. Afterward, our application template had:

• Shared libraries for error handling, heartbeat, and standard configuration.
• Logging and error-handling recommendations and examples.
• Common settings for HTTP listener and response connectors (including mTLS for local testing and autodiscovery).
• Code examples of common synchronous and asynchronous patterns recommended for use.
• Naming conventions for name property files, flow and Mulesoft config files.

We used meetings/chats to discuss daily or weekly what needed to be added to the template. Everybody contributed, and we also started to leverage that template for our new implementations.

We constantly updated the template with new versions of plugins or recommendations that could contribute to the project and future.

As a result, developers became more and more focused on the implementation of business logic for new functionalities, which, in turn, increased the velocity of project delivery.

Further, onboarding new developers went quickly and smoothly, and the application template contributed significantly. Eventually, I wrote a short documentation explaining only the main aspects of the project. The details were inside the template. :) The template served as a prominent part of our documentation.

By the time we finished the POC, we had created a stable template that reflected all the best practices we had adhered to and recommended for future business implementations. 

What if We Did Not Have the Application Template?

Then, the onboarding would be a slow-moving process, and we would have risked not completing the project on time. The application template helped to answer these questions quickly and accurately:

• What application can be a template for a new business implementation?  
• What are the requirements for logging, error handling, code review, and naming conventions? 
• How must the new applications be structured and organized inside (properties, patterns, etc.)? 

There was another significant benefit: since all new applications were traced back to the template, a developer could easily read code written by another developer and understand the functionality of other applications. 

Our application template helped us strategize the work in the solution delivery, and the POC was completed on time.