3 Regrets as a Junior MuleSoft Dev

There is a famous saying. “Hindsight is 20/20”. Today I am reflecting on three things I regret or wish I would have done more as a Junior MuleSoft Developer. This post is the second of a series for Aspiring MuleSoft Developers. To see the first post, click here.

My List:

1. Build MUnit Tests

2. Practice DataWeave

3. Learn Integration Patterns

Build MUnit Tests

I have a secret, and I’m not too proud about it. As a Mule 3 developer, I seldom wrote MUnit tests. It wasn’t until I started developing in Mule 4 that I began to regularly incorporate MUnit tests with my code. The funny thing is I’m not alone. Two months ago on LinkedIn, I asked my fellow MuleSoft developers and architects, “How do you test your Mule APIs?

From those results, 88% of MuleSoft developers and architects used MUnit or a combination of manual testing and MUnit. The remaining 12%, either used some other tool to unit tests or just performed manual testing.

Why is writing MUnit tests important?

Writing MUnit tests along with your Mule code is a best practice. Not only does MUnit serve as unit testing framework, but MUnit test cases can be incorporated in your CI/CD pipeline as integration tests. You could set up your pipeline to prevent deployments if any of the MUnit tests fail.

If I could do it all over again, I would force myself from the start of my MuleSoft career to complete MUnit test cases when delivering my code.

Practice DataWeave

Coming from a Mule 3 development mindset, I was used to transformations being applied through many different transformers, including DataWeave. Mule 3 gave developers the option of using multiple transformers, Mule Expression Language (MEL) and DataWeave 1.0.

Why is practicing DataWeave important?

Although I knew DataWeave was powerful, I had the mindset that DataWeave was just a transformation language. Well, guess what? In Mule 4, our friends at MuleSoft removed the transformers and MEL and left us with DataWeave 2.0. More than a transformation language, DataWeave 2.0 improved features in DataWeave 1.0 and was marketed as a functional programming language in its own right. This meant that I would have to improve my DataWeave skills.

Some integrations go beyond Anypoint Studio's drag-and-drop mapping feature and require you to know the language. I find building DataWeave scripts to be something that I spend a lot of time on. So, I recommend that all aspiring and new MuleSoft developers spend time learning DataWeave. The drag-and-drop interface is a good starting point, but your employer or client will eventually intermediate to complex transformation requirements.

If you enjoy tech books, MuleSoft for Salesforce Developers DataWeave Exercises is a must-read.

This 15-chapter book serves as an introduction to Mulesoft and its products. It's marketed towards Salesforce developers, but all aspiring MuleSoft developers can use this book. Chapters 6 and 7 are dedicated to DataWeave, which alone is an excellent reason to check it out.

If you are interested in the review. Feel free to read here.

Learn Integration Patterns

Just as a software engineer would invest time in learning design patterns, you should invest time in learning integration patterns.

Why are learning integration patterns important?

Integration Patterns are integration designs (or blueprints) that have been proven to work in the industry and are looked at as best practices. Knowing these patterns can help when building complex integrations. I recommend checking out the Enterprise Integration Patterns: Designing, Building and Deploying Messaging Solutions by Gregor Hohpe and Bobby Woof.

Conclusion

These are three areas that I wish I would have learned more about as a Junior MuleSoft developer. New developers, do you have any topics you are interested in learning? Senior developers and architects, what were some MuleSoft topics you wish you would have learned earlier?

Lastly, subscribe to my social media and/or blog in the footer section to ensure you do not miss a post.