Microservices at the Front: Micro Front-Ends

Microservices vs. front-end

Microservices architectures have become the default option when building or modernizing digital software products.

Our survey with CIOs confirms just that.

There are different levels of maturity for microservices architecture, with the least popular element of it being micro front-ends. Let’s take a look at the promises of microservices (again).

→ Read more about Evolutionary architectures in practice

Benefits of microservices

The promise of the microservices paradigm that has been fulfilled was the enabling of independent teams to work on the autonomous parts of the system. It allows service-oriented organizations to parallelize the work easier and speed up the software development process.

What can be achieved by using this architecture is the ability to design, develop, test and deploy its parts independently from each other. With an effective devops pipeline and toolset, and a proper decomposition of the application to the microservices,  we can now see the rise of a continuous deployment and a much shorter time from development to production. Shipping features faster is always something that businesses want for their users both externally and internally.

Another benefit is the higher resilience of the application. If some parts fail due to bugs or infrastructure failures,  other parts should be still operational because of the separation.

→ Explore more To change or to pretend a change – that is the question

Why micro front-ends?

The high price to pay for flexibility is providing true autonomy of the services in order to be able to develop, test and deploy them separately.

So as usual,  initially there was some misunderstanding and a blind eye turned towards the core principles. We can see many variants which for some are violations and for others optimization/simplification.

Let’s start with the monolith.

Monolith

Layers that are vertical, and have no separation of services. It was a classic model for almost twenty years for web applications.

Monolithic database

Simplification, which used to be very popular in the beginning of the microservices revolution, can still be found today.

For some it’s simplification, for others it’s the total violation of the core microservices principle of autonomous deployment.

And by the way (spoiler alert!), the UI is also monolithic.

Monolithic front-end

The more popular approach is to divide data sources into services thus making them independent. Different databases or namespaces enable different teams to work separately on their modules consisting of tens or hundreds of microservices.

Still, on top of it there’s a monolithic UI so in case of any changes to the front-end layers,  the whole monolithic UI has to be deployed.

This is so popular that many don’t recognize it as a problem, as they are focused on the server side of the microservices architecture.

Micro front-ends

I hope it was easy for you to guess what is next. The UI elements are separated now and the parts of the application can be designed, developed, tested and deployed independently.

Of course if the UIs were completely separate, we would have to open multiple web pages, for instance, which is not a practical solution for the end users. So, different types of UI aggregators are on top of the architecture to provide a single UI for the users built from autonomous components, which are parts of ‘micro applications’ (from database, through business logic, API layer to UI interface).

The UI components can communicate by sending messages to each other, sharing the same authentication context from the container; usually in the form of an authentication token, otherwise we would have to login to each part separately which is not practical at all. Of course the principle of zero shared state is strongly recommended.

The integration between autonomous front-ends can be done in several ways:

• Build time integration:  highly not recommended as it requires deployment of all front-end components at the same time thus destroying the benefit of autonomous deployment.
• Run-time integrations:  strongly  recommended by using top level containers that are responsible for layout and interaction with independent micro front-ends which are represented as DOM elements on the web page and events.

Adoption of micro front-ends

Enablers

The most popular front-end open source frameworks, such as React, Vue and Angular, support micro front-ends, so there’s no technology barrier or a necessity for abandoning the well known front-end stacks.

Micro front-ends are often considered the final level of microservices architecture adoption. Now, the teams can be fully separated from each other and work independently from each other, as there’s no single UI team which is considered a bottleneck.

Micro front-ends also help with incremental updates of the application, which is always important, especially when doing a legacy system transformation into a modern one.

Challenges

The adoption is slowed down by the cost of dividing UI layers into separate modules/services. Other problems which can be mitigated, but not fully avoided, are CSS/JS conflicts and in general the fear of destroying the unified look and feel when all the teams are separated.

Future of micro front-ends

In order to achieve truly cross functional teams that can deliver features in a given group but independently from each other, the micro front-ends seem to be a necessity. It’s considered the final step in the adoption of the microservices paradigm for this reason.

It’s so easy to neutralize the benefits of the microservices paradigm by creating a monolithic front-end, and we’ve seen this many times before. I expect modern enterprises to embrace this architecture more and more.

We, at Avenga, know when to use the micro front-end paradigm and how to use it with different front-end frameworks. You’re more than welcome to work with us on the proper design and implementation of micro front-ends for your modernized or new digital product.