How to... API LED architecture

Hello everyone!
This is the first article that I publish on this my very personal website/blog and I don’t hide from you that I feel a little bit of emotion. Never having done frontend, for me it was a nice challenge to manage to set up something that I deemed satisfactory and I consider the result a great achievement! 😁

If you happen to find some bugs here and there, please inform me, so I can face them in the hope of having the best.
If instead you just want to leave feedback (even to tell me that you think it’s terrible!) I will be more than happy :)

But let’s get back to us, I’ve been thinking for a long time about the topic of my first post and in the end I discarded many more technical options (which now sit in the backlog and will come in the future) opting to start from the basics.

Today I want to talk to you about a topic that is always relevant in our world: the architecture of our IT infrastructure!

Every professional who starts his adventure in the MuleSoft world must know the principles of the API Led architecture, but in this post we make a brief recap for those who may be new and less familiar with this tool.

The API Led architecture is the architectural model promoted by MuleSoft that is based on the optimization of our microservices network through the reuse of components: the goal of this model is to contain what is called “technical debt” (i.e. the time that every IT team has to spend mantaining their own applications) reusing as much as possible every single application that will then be developed trying to keep it as agnostic as possible to the specific business flow that we are implementing.

“But Marco, how is this possible? There are needs that will force you to create coupling between the code and the clients that will use your APIs!”

Correct!
Obviously the API Led takes this need into account and therefore responds to it, let’s help ourselves with a graphic scheme (thank you Unity Group), so as to facilitate the introduction of another key concept of the API Led: the layers.

• Experience: it is the layer that responds to the customization needs of each user of our APIs, it is responsible for receiving and returning data in a format compatible with the clients that call us and at the same time packaging the data so that they can be consumed by our internal layers. They are obviously the least reusable applications and are usually divided based on the channels that need to consume our services (mobile, web, CRM, etc.).
• Process: it is the layer that corresponds to the heart of our business operations. These applications usually play the role of orchestrators and achieve their goal by talking to other process and systems. Together with systems, they are the applications that are reused as much as possible and are usually divided based on the scope of the flows they orchestrate: products, customers, blockchain and so on.
• System: it is the lowest layer in our architecture, usually also the most “stupid”. They are applications that talk directly with third-party systems or data sources and as such must remain absolutely agnostic in order to be reusable 100%. They are composed of linear and flat processes that do not perform any form of logic that is not strictly necessary.

Now that we have introduced API Led and its principles, let’s give a practical example of how these could come to our rescue. Let’s imagine a scenario where we’re working on a first project with a customer where we manage users registration, with data that is saved both on CRM and DB:

We could approach the project with an architectural footprint similar to the image proposed above. And what would happen if the customer later asked us to integrate everything with a second access channel for mobile in addition to the one for web-apps? What would be the impact on our applications?
Let’s observe it in a second image:

The changes would be minimal, as we will simply need to provide a new entry point to our ecosystem by creating new specific APIs for mobile clients.

If you now try to imagine this dynamic extended to a mature ecosystem, and with several processes already developed, you will understand that the savings in terms of maintenance and development time are huge and with these comes economic savings for the customer that you are assisting.

One important thing I want to emphasise is that the principle of layers is here to make our work easier and we must never become slaves to it!
If a flow does not need to orchestrate any logic, we can bypass the Process layer and make Experience and System interact directly, unless we feel that having a Process in the flow will make it easier for us in future evolutions of our infrastructure.
Similarly, we do not need to get rigid with the Experience > Process > System hierarchy, a Process could call another Process for example.

Soon we will discuss in an article focused on Anypoint Platform the tools available to us to make even better use of API Led, with the hope that it will help you to better understand the added value of Experience APIs which are usually the layer that beginners have more difficulty approaching, often considering it superfluous.

That’s all for today, thank you very much for reading and if you have any doubts, concerns or disagree with what is written, feel free to send me a message on LinkedIn to discuss it, I consider discussion the basis for growth and I am always open to debate!

See you next time! 😄