The term "Micro Frontends" is becoming more popular this days. As there are lot of discussions going on regarding its implementation, Whether we should or shouldn't adopt micro-frontends yet. Let's see what micro-frontends really are.
What are Micro-frontends Anyway
If you are a backend developer, you might be already familiar with micro-services architecture. But for the front-end developers, it's not that common yet.
Micro-frontends are basically an architectural pattern in which a front-end codebase is decomposed into individual "microapps" consisting of different frameworks / libraries working loosely together, Obviously inspired by backend micro-services.
We could have something like this :
If you notice each microapps can be built with different frameworks or libraries and each microapps can be owned by a single team.
Why Micro-frontends ?
When I was first introduced with micro-frontends honestly it felt a bit off for me and so is to @dan_abramov
But as I started getting familiar with the concept, I realized there are multiple reasons for using micro-frontends. One of the biggest reason would be when migrating from old codebase to a new framework or library.
Problems with traditional monolithic architecture
In early stages of an application it might not be a big problem, But when application grows, the number of teams increases then it becomes a real challenge . When project is massive it becomes difficult to work with multiple people/teams. Unnecessary codebase being available due to which build time is increased. When using same micro-service API it is difficult to make changes when API responses are refactored.
Micro-frontends to the rescue
Adopting micro-frontend approach we could solve some of those problems like assigning individual team with core modules. As unnecessary codebase is removed it is easy to deploy and build time also decreases. individual microapps can be developed, tested, and deployed independently, separate modules can be inserted , removed, or replaced without any refactors, different modules of the frontend can be created using different frameworks or libraries. As organization requirements changes we can easily replace old modules with new ones. So we will continuously evolve our codebases.
Some of the big companies are already using it, to name few Spotify, Klarna, Zalando, Upwork, AirBnB, and Facebook.
Different approaches towards micro-frontends
Well while adopting micro-frontend architecture we have few approaches which can be used :
Using a framework
We can use Single-SPA which lets you combine multiple Frameworks or libraries in a single page.
Using Web Components
Web components can be hosted on different servers with different frameworks or libraries. Chris Kitson has discussed it in depth here : Creating Micro-frontends using Web Components (with support for Angular and React)
Using a separate micro-service for each micro-frontend modules, which can be very beneficial when API changes.
Challenges in micro-frontends
As it comes with many advantages it also have some disadvantages too, while application grows we would be left with tons of codebases to maintain and to maintain the same best practices among all the microapps. It would be very hard to run tests on the the entire codebase locally. While different microapps are hosted on different servers there might be some performance issue which costs user experience. Inter microapps communication can be very difficult and complex to work on.
So basically, micro frontends are all about splitting up big modules into smaller chunks i.e. more manageable modules, and then being explicit about the dependencies between them. According to me Micro-frontend are the future we are heading into but there's still a long way to go. It certainly depends upon the organization requirements and how big the development team is. I hope you have enjoyed this article and got a sense of what micro-frontends really are and different approaches to it.
Thanks for reading, stay awesome! ❤