Micro Frontend: Everything You Need To Know

Micro Frontend: Everything You Need To Know

Microfrontends are quite a hot topic in frontend development. In short, it is the division of a monolithic application into semantically isolated parts and their independent development. Each page of the site or application is structured into blocks, it can be an advertising block, a feedback block, and so on.

They interact with each other according to the logic conceived by the developer, but they can be developed, tested and deployed as separate applications.

The idea itself is not new and comes from the world of the backend - it is a microservice architecture. The idea is the same: we have a big application which needs to be maintained and developed.

There are several teams working on it, each one doing a different part. In the logic of a monolithic backend, it's not easy to develop your part without risking affecting the functionality of the other part of the application. Therefore, the backend divides the application into microservices and develops them in isolation, but in such a way that they continue to interact with each other.

Microfronts, like microservices architecture, are the result of a natural evolutionary process. The old monolith approach was convenient in many ways, but as technology becomes more complex and applications grow, it has taken its toll. Monolith is poorly scalable, difficult to support, develop and test.

The classic way to deal with complexity is to break it down into components. If it is difficult to develop the whole application, you should "saw" it into parts and develop it separately.
Where's the catch

The logic of microservices is superimposed on frontend development. Front-end programmers also wanted the flexibility and independence of commands, the scalability that is characteristic of microservices architecture.

One thing: the frontend always works with a single environment, which is hard to separate. It runs on the browser (client) side, so there is always only one address bar, one global localStorage object, one DOM within a single application. No matter how we divide the application, some common part always remains. It is around this problem that the main limitations of microfrontends are built.

And the main frustration: it is not possible to organize the same isolation of application parts within the microfrontend as it is in microservice development in the backend. At least for now.

Since complete isolation cannot be achieved, front-end programmers still have to accept any changes in the code in a very deliberate way. Therefore, developer expertise is very important when developing an application in microfrontend logic. They have to understand how a particular change in code can potentially affect the application as a whole.

If you want to migrate to microfrontend

First and foremost, understand why you want to do it. Microfrontend isn't for everyone. Yes, it's a trend that's being actively discussed in the community. Yes, many large companies will come to this architecture one way or another.

But all this is relevant in case of a voluminous application. If the site consists of several pages, the microfrontend makes no sense. It's already overhead. The monolith division makes sense if you have a large project, several development teams who may be using different frameworks.

This, by the way, is another plus of microfrontend: different teams can write code on different stacks. Some write in React, some write in Angular, but everything comes together to make one application work.

Then you need to figure out exactly how to divide your monolith into relatively independent blocks for development. The most common way to do this is to start from the development teams. Usually the division of areas of responsibility is already there, it's just not embodied in the architecture.

Choose tools to help you build a microfrontend architecture. Now there are more and more libraries, tools that help developers on their way to microfrontends. For example, a library like single-spa, which combines multiple javascript applications into one. Or the Realms specification, which will simplify frontend microservices development at the native javascript level.

Modern frameworks like Vue and Angular also have some features that allow you to write your application in a way that makes it easier to integrate into microfrontends as a result.

How to solve the problem of shared resources

A good step toward organizing microfronts can be to create a mono repository. This is a git repository that contains your npm packages that depend on each other. A mono repository will help solve the problem of conflicting library versions and maintaining development by different teams - everything in one place, no need to run through different repositories and linking packages.

I will also mention the obvious things: you should not exclude the best development practices (including DRY, KISS, YAGNI) and simple communication - sharing experiences between the frontend developers of the company.

Highlighting the key

Microfrontends are about dividing a monolithic application into semantically isolated parts and developing them independently.

Microfrontends make sense if:

  • You have a large application.
  • Multiple development teams.
  • You have increasing problems rolling out updates to the app.
  • The advantages of a monolith have turned into disadvantages.

For other projects, microfrontends will be redundant.

Limitations of microfrontends:

  • There remains the problem of shared resources. Full isolation, as in the case of microservices architecture in the backend, is not yet possible.
  • An application orchestration layer is required, which can contribute its own overhead.

Which would help with the limitations:

  • Creating a mono repository.
  • Use of special libraries and tools.
  • A good team of specialists.
  • Using best development practices (e.g. DRY, KISS, YAGNI).