Introduction

Micro Service is a fast-spreading architectural style in software development, and we’ve already written about it here. Now is time to take this approach a step further and see how microservicing can be adapted to the front-end in creating the so-called micro-frontend. The scheme here is the same and it consists of decomposing monolithic frontends into smaller and simpler parts that can be developed, tested, and deployed independently, while still appearing to users as a single cohesive frontend.

Here are some of the reasons why we decided to shift to Micro-frontends.

1) Monolith frontend is too complex

Over time the front-end we had been working on had grown immensely. We were dealing with a monolith frontend that was hard to scale from the development point of view. We realized that large applications that are built by using monolith architectures have a lot of dependencies, and coordination became harder and more time-consuming.

2) Need for simplicity

The code of each micro-frontend is by definition much smaller than the source code of a single monolithic frontend. These smaller codebases are simpler and easier for developers to work with.

3) Team organization

As we have more front enders working on the same team, we need each one to be proficient on a single part of the project in order to avoid dispersion. Micro-frontend provides the capability to compartmentalize work, therefore higher efficiency.

4) Faster Onboarding

A big codebase is complicated and the onboarding of a new front ender is time-consuming because the project has become too large and there are too many things to go over. Micro-frontend allows to split the big picture into smaller and easy-to-understand frames, therefore one only needs to learn about what he/she will be working on.

5) Independent development

This is by far the greatest advantage we have drawn, in fact since each micro-frontend application is independent, changing one application will not affect the other parts (as long as they are separated). My team can have individuals working parallelly without the need to be coordinated.

6) Independent deployments

While updating a monolithic web application, you need to update the whole thing. You cannot update just one piece while keeping the rest the same because it would cause problems in the website, therefore coordination is mandatory. Instead, with micro-frontends, teams can deploy at their own speeds without waiting for external dependencies to be resolved before deploying in production. This concept is valid also for testing.

7) Future proof

Another reason why we choose this approach is the evolving nature of frontend development. Let’s say a new framework takes over and we start using it. Micro-frontends architecture allows new frameworks testing and integration so teams are free to choose their favorite technology.

8) Choose your favorite programming language

With micro-frontends, each package can be written in a different language (Angular, React, Vue, Svelte, etc). This allows teams to be agnostic when developing since they can choose whatever language they want.

Takeaways

Micro-frontends enable teams to develop independently, quickly deploy, and test individually, helping with continuous integration, continuous deployment, and continuous delivery. We strongly recommend you to look into microfrontending since it can be the best solution for your product. In the next article, I will cover why and how we use Module Federation for achieving micro-frontends.