Last year I saw the term "Micro Frontends" become more common than before.
In the world of backend developers, it's already more common to split everything into microservices. Thanks to the techniques of Docker, it's easier than ever to scale the backend into multiple services and instances of those services.
But in the world of front-end developers, it is not that common yet.
In this post, I want to share my thoughts on why I think going from a monolithic front-end application to a micro frontends approach could be good.
Why?
The micro frontends approach feels a bit off for all those front-end developers that build websites or web apps for years in a monolithic architecture. (Well, that is my first opinion when I discovered it).
Problems with monolithic frontend
When you think about the challenges we have with a monolithic frontend application:
- Harder to work on with multiple people/teams
- Long build times
- Overrides of styling without knowing it
- When API's have breaking changes, the whole application needs to be deployed
When you first start to build a single website, this is not a big problem. But when the organization grows, the number of people that work on it will become a challenge.
Problems to be solved with micro frontends
Switching to a micro frontends approach could solve some of those problems.
- Easy to deploy in small parts
- Shorter build times
- It's easier to work on with multiple people/teams
- Breaking API change will only require 1 small deployment
But it will take a different mindset for the development team. Next to that, it needs some additional work to change the frontend architecture.
How
Lucky enough, we are not the first developers who have experienced these challenges with the monolithic frontend architecture.
Big companies lead the way
Big companies like Spotify, Klarna, Zalando, Upwork, Allegro, HelloFresh, AirBnB, and Facebook have experienced these challenges too.
So they pioneered a lot with this and found some cool approaches to solve the problems.
- Zalando build Mosaic9. Check their talk about it: Mosaic Microservices at Zalando Tech
- Klarna explains on HN how they approach it
- Upwork has written a blogpost: Modernizing Upwork with Micro Frontends
- Allegro has written a blogpost: Managing Frontend in the Microservices Architecture
- HelloFresh has written a blogpost: Front-end Microservices at HelloFresh
- AirBnB created a tool called HyperNova to serve JavaScript views server-side
Techniques
If you checked all the posts of the big companies, you could see a few techniques on how to approach the micro frontend technically.
- Meta framework: Single-SPA, this framework lets you combine multiple JavaScript Frameworks/libraries on runtime without refreshing the page.
- Multiple SPA on different URLs: This is the simplest way of having multiple micro frontends
- IFrames
- Web Components: Using a JavaScript wrapper to turn your Angular and React components into Web Components and serve them next to each other. Chris Kitson created a cool and practical blog post about it: Creating Micro-frontends using Web Components (with support for Angular and React)
When
But the question, "when would it be a good idea to switch to micro frontends?". Well, I think it's relatively simple to stick with the monolithic approach when you build a small website. When you build a big application, work with many people/teams and use "microservices" as your backend architecture, you could definitely benefit from the Micro Frontends approach.
Thanks
Thanks for reading all the way down to here 😅. I hope it gave you some material for your investigation of Micro Frontends.