Thoughts About Micro-Frontends in 2020
Why it could be good to break up your monolithic front-end codebase
In the last few years, I have seen the term “micro-frontends” become more common than before.
In the world of back-end 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 back end 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 it could be good to go from a monolithic front-end application to a micro-frontend approach.
For all those front-end developers who have been building websites or web apps for years in a monolithic architecture, the micro-frontend approach feels a bit off. (Well, that was my first opinion when I discovered it.)
Problems with monolithic front ends
When you think about the challenges we have with a monolithic front-end application:
- Harder to work on with multiple people/teams.
- Long build times.
- Overrides of styling without you knowing it.
- When APIs 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 solved with micro-frontends
Switching to a micro-frontend approach could solve some of those problems.
- Easy to deploy in small parts.
- Shorter build times.
- Easier to work on with multiple people/teams.
- Breaking API changes will only require one small deployment.
But it will take a different mindset for the development team. Besides that, it needs some additional work to change the front-end architecture.
Luckily enough, we are not the first developers who have experienced these challenges with monolithic front-end architectures.
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 built Mosaic9. Check out their talk about it: Mosaic Microservices at Zalando Tech.
- Klarna explains on HackerNews how they approached it.
- Upwork has written a blogpost: Modernizing Upwork with Micro-Frontends.
- Allegro has written a blogpost: Managing Front end in the Microservices Architecture.
- HelloFresh has written a blogpost: Front-end Microservices at HelloFresh.
If you’ve checked all the posts of the big companies, you would have seen a few techniques on how to approach the micro-frontend technically.
- Multiple SPA on different URLs: This is the simplest way of having multiple micro-frontends.
But the question: “When would it be a good idea to switch to micro-frontends?”
Well, I think it’s relatively simple. When you build a small website, stick with the monolithic approach. When you build a big application, work with a big amount of people/teams, and use “microservices” as your back-end architecture, you could definitely benefit from the micro-frontend approach.
Thanks for reading all the way down to here. I hope it gave you some material for your investigation of micro-frontends with a microservices architecture.