I'm still not a Mulesoft expert yet

Development

After a very busy and difficult couple of months, the system I’d been working on is about to go live to ~27,000 users, and I’m feeling slightly pleased with myself. What should have been a simple integration morphed into a complex Mulesoft project. What a learning curve that was!

The following is my experience with Mulesoft so far.

I think the one advantage Mulesoft has over other platforms - and maybe its selling point - is that the Anypoint portal provides us with a single place from which numerous integrations, API specifications and deployment environments can be managed. I also like the idea of having all that on just a couple of servers (one as backup, obviously). This is a vast improvement from having ~120 integrations, developed using various frameworks (.NET, SQL, Logic Aps, Node.js, PowerShell, etc.), hosted on numerous servers. The deployment process for Mulesoft applications is a little more complex, but it’s something that can be standardised.

Again, the steep learning curve is frustrating at times, when starting out. Mulesoft developers need good background knowledge of REST APIs, JSON, SQL, OAuth and version control. The documentation out there isn’t great, and there isn’t a lot on Stack Overflow either, so I ended up creating my own volume of documentation for hacks, fixes and workarounds.

Essentially Anypoint Studio generates a vast amount of XML, which determines how numerous Java components and packages are compiled into a single .jar file that’s deployed on the Mulesoft server. Most the development will be around configurations, which are stored in half a dozen places. If you want an HTTP Request, the URIs should be read from whichever configuration file, and the file path for that will be determined in global.xml and the run configurations. If you need to use the ClientID and ClientSecret, both need to be encrypted elsewhere, stored in another set of configuration files and decrypted using a key in the run configurations. And there are other environment variables that need adding later.

After deploying an application to the production environment, I was presented with a new set of problems that weren’t apparent during the unit or integration testing. Basically CloudHub’s resources are easily maxxed out, and applications restart themselves when trying to handle more than ~50MB of JSON. Additional work was needed to make the application more efficient and robust.

  • Set variables to null after they’re no longer needed.
  • Exception handlers are needed for everything. I’ve come across many questions from other developers about how to terminate an application’s flow: My solution was to use try/catch, with the catch referencing a sub-flow that contained only a logger component.
  • Add unit tests for everything. I typically run them in debug mode, with breakpoints set on components I’m interested in.
  • Make liberal use of the core logger component. This really does help in tracing post-deployment issues.
  • When paging responses from another Mulesoft API, the connection is likely to be closed once or twice, and that results in data issues. I put the HTTP Request inside a ‘Until Success’ container, set the retry number to ‘5’, and increased the timeout to something like ‘60000’.
  • Make sure the application is configured to use Object Store version 2.