Microfrontends explained

I'm addressing this topic because I get a feel that Microfrontends are no longer just a buzzword, they are being adopted rapidly in large web applications.

Microfrontends might be the next big thing in frontend development.

Let me tell you why!

What are Microfrontends?

Microfrontends is a software architecture pattern for frontend code. It is influenced by the backend microservices architecture pattern.

To understand microfrontends and why do we need them, we first need to know a bit about microservices.

Microservice architecture – a variant of the service-oriented architecture (SOA) structural style – arranges an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight. (Wikipedia)

An example - if we would have a Webshop microservice backend, in which each service is owned by a team, we could have the following microservices:

• Products
• Products catalog (management)
• Reporting
• Customer
• Orders

Note: This is a simplified view of a microservices architecture & in a real-world application we could have tens or hundreds of microservices.

In the frontend world, for an application like this - we could have:

Notice a few things:

• each microfrontend can be built with different technologies
• each microfrontend can be owned by a team
• each microfrontend can depend on only one microservice

Why Microfrontends?

What advantages does this bring? Well, quite a few.

Remember that time you joined a dev team on an old project and the frontend was still built with XSLT & jQuery? A re-write was not even considered and you had to use those old technologies to add new features and fix bugs.

Even if you could convince the stakeholders to do a re-write, and you have a new codebase for 1-3 years. What makes you think in 10 years it won't be perceived as XSLT & jQuery are today?

Microfrontends promise:

• smaller, more maintainable codebases
• each microfrontend can be written with different technologies - this removes as much as possible external dependencies
• each microfrontend can be handled by a different team - reduce cross-team dependencies
• we can update/upgrade or delete microfrontends whenever we think it is needed

As a business a commitment needs to be taken - we will constantly be replacing old micro/services/frontends with new ones. So we will continuously evolve our codebases.

Example:
We could delete an old framewok.X.js microfrontend and completely swap it with the new one written in framewok.Y.js. This reduces the risk of an entire app rewrite.

Different approaches

There are different approaches to build microfrontends.

Option 1 - One microfrontend for each microservice 🤖

This option is fine when the microservices architecture is based on features. We can have a feature microservice - for example for checkout, then we also build a checkout microfrontend. The advantage here is that each microfrontend needs to know exactly about one single backend API.

Option 2 - Web components 🌟

Those days, a lot of UI frameworks provide support for web components (Svelte being pretty good in this area).

We can have a legacy UI and constantly swapping old code with new Web components. Each new web component can be a microfrontend written in Svelte, Vue, vanilla JS, or whatever you prefer.

The code for each web component can be hosted on a different server, so individual deployment can be done easily without affecting the rest of the system.

Option 3 - using a Microfrontend tool 🛠️

You can use a tool like single-spa to achieve the wire up of different microfrontends.

This approach fits best for building new microfrontend applications. If you decide to use single-spa make sure you read thoroughly their docs and look at their recommendations.

Option 4 - Module federation ⚙️

This is a Webpack 5 feature that achieves:

Multiple separate builds should form a single application. These separate builds should not have dependencies between each other, so they can be developed and deployed individually. (webpack)

As Webpack Module Federation seems quite stable, this option looks the most exciting at least for projects that use Webpack. Module federation allows for modules sharing so things like loading the same version of React or Angular twice can be avoided with proper config.

Note: you can also combine those options to achieve the architecture that you need. For example, you can use single-spa with module federation.

Can I afford microfrontends?

Microfrontends are certainly not for every use case.

Micro/frontends/services tackle the problem of software rewrite and software scalability. Independent deployments are also very important for micro/frontends/services.

It also relies on the fact that the company has a big dev team, so in this case, it's much easier if not all devs work on a single codebase, stepping on each other's toes all day. Instead, those devs will be split up in teams, each working on a set of a few or maybe only one micro/frontends/service.

The problems with microfrontends

Obviously, there is nothing without a set of disadvantages, so let's look into what are the drawbacks of microfrontends:

• hard to test the entire codebase locally when there are many micro/frontends/service
• very strict interfaces need to be designed upfront
• more codebases to maintain, upgrade & address security risks
• performance cost on the end-user, having to download the applications code for each microfrontend
• the communication between microfrontends can get very complex
• the infrastructure & deployment will probably get more complex as well

More Resources

Conclusions

I hope this article makes microfrontends and what they represent more clear to you, thank you for reading!