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
- Team Scalability: Multiple teams can work independently to contribute to multiple systems. This allows us to divide the work and scale it through multiple teams.
- Single responsibility: This Will allow each team to build components with a single responsibility. The hosting team can focus on analytics, performance and each feature team can focus on customers. Both teams can work 100% on their particular areas. The host page team can focus 100% on creating a great host page. Each Micro Frontend team will focus 100% on the functionality of their Micro Frontend.
- Reusability: We will be able to use code in multiple places. One component will be built and deployed and different teams can re-use it.
- Technology agnosticism: Micro Frontends architecture is independent of technology. You can use components from different technology (JavaScript, React, Vue, Angular ...). You do not have to worry about deploying or building them.
- Learning Curve: For new engineers joining the teams, it is easier to learn smaller apps than understanding a monolith with thousands of lines of code.
Different approaches
Option 1 - One microfrontend for each microservice 🤖
There are different approaches to build microfrontends.
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.
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