I’ve worked with several ’low code’ platforms in recent years. Some are better than others, but I’m always asking one question: What problems are they supposed to solve?
The biggest of them is ’technical debt’. Dependencies become outdated and unmaintained, updates sometimes have breaking changes that require code to be reworked, additional code gets tacked on over the years by various people, amateur code makes that harder, etc. Technical debt might be an inevitability for an organisation that’s been developing software in-house for long enough.
Typically I find that some troubleshooting and configuration is required to get an imported project to a state where it builds and the unit tests run, and the reasons usually aren’t obvious.
Importing a project Most Mulesoft developers would have made the mistake, at least once, of trying to import a project using one of the options under the ‘General’ section, as that’s the first displayed in the import options window.
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.
Getting software to work with OAuth is usually one of the easiest things a developer could be tasked with, if s/hehas done it a few times: Create an HTTP client method that sends four values to an OAuth provider, then pass the response to the next HTTP client method as a variable to be used in the Authorization header.
Doing that in Anypoint Studio, for a Mulesoft application, was an uphill struggle of resolving one error message after another.
Anypoint Studio, as a development tool, comes with a steep learning curve - it’s essentially a rebranded version of Eclipse, with a lot of custom Java packages (there are a lot for the Mulesoft server) and a package manager pointing at the Exchange repo.
Putting together a Mulesoft application, using the ’low code’ designer and DataWeave is easy enough, though I haven’t done any advanced data transformations yet. Currently it relays data from another Mulesoft API to an external service in a different format.
It took a while to get everything set up for the Mulesoft Development course, with the following being required:
Anypoint Studio Anypoint Platform account (separate to the training account) Salesforce account Advanced REST Client (Probably wasn’t needed, because I already had Postman installed) There are a few things to be aware of:
A considerable amount of disk space is required for Anypoint Studio and the training files. I reckon it’s somewhere around 4GB.
