Last years I see 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 it could be good to go from a monolithic front-end application to a micro frontends approach.
Why?
For all those frontend developers that build websites or web apps for years in a monolithic architecture, the micro frontends approach feels a bit off. (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
- 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 find 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, 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 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.
Top comments (14)
Every time i see "microfrontends" it feels like something very hype'y that in 5 years time we will be reading a post-mortems about how it really sucked, cost a gadzillions of dollars and when it breaks its impossible to pinpoint and fix quickly.
Complexity and abstractions come with a price, and it is usually a very high price to pay - the bigger the team and project, the bigger the price. Ask those who failed at microservices.
Just my gut feeling. Frontend guys trying to do everything that backend guys swallowed last week to make boring day to day job a little bit more exciting doesnt seem like a good idea.
Well I disagree. We've used microfrontends where I work for about a year and a half now. It has really simplified my job. Apps are significantly smaller which means significantly less complex. There's a much lower chance of breaking anything. And it forces us to write clean reusable components. No more insane spaghetti code monoliths.
Thats why i wrote in 5 years, because usually architecture nightmare blows up in a longer term, not 1 year.
PS. Im pretty sure 10 small spaghetti apps will be worse to maintain than 1 spaghetti app, but what do i know ;)
I guess I don't see your point. You're just staying an opinion, which is fine, but it seems baseless. You're saying a microfrontends is more complex than a monolith. I disagree. Having done both I'd say microapps are much easier to develop and maintain. Pulling them together isn't very hard either. Have you used single spa?
This sums it up well.
If dev dont know how to write code, dev will make 💩 in any architecture.
The complexity on top of micro* will create additional mess that will be harder to handle.
Problems with architecture are long-term and surface after some team rotation, legacy code creation, test neglecting, etc. But you have some years until then, so dont worry ahead of time ;-)
So your argument is that bad devs write bad code? ... Alright well I'm gonna bow out of this one. Unless you have a more substantive argument.
Can you elaborate more on how you split your frontends, just high level, do you do it by feature or by some other method?
This is wrong. Just to elaborate why: Certainly we will read these post mortems - we read them about microservices, too. The reason is not that microservices suck, but that the pattern has been applied by the wrong people and / or for the wrong reasons.
The same is true for microfrontends. They are not for everyone. If everyone uses this pattern then something is wrong. It's just another tool and people should finally stop thinking in terms of "only X is best".
If your problem can be solved with a monolith then you should go for it. That's true on the backend and remains true on the frontend.
Those post mortems also usually mention couple things that apply specifically to micro* things:
1) devops is much more expensive
2) deploys are harder
3) debugging is harder
4) rollbacks are harder
5) architecture is much more complicated, ergo more error prone and when SHTF in one of them, usually most of the things are down
6) pool of devs that can work on it is much smaller, because not everyone is interested in banging head against docker for a day every month when someone changes something somewhere (especially frontend devs dont like it)
7) logging is harder and more expensive (usually need external service to aggregate)
... and many more.
So, as famous Aaron Patterson said... "But at what cost?"
IMO If you dont have enterprise human resources (why enterprise? because they are a waste machines and they dont care), its just huge mistake to divide to micro*, especially micro frontends.
Some of these things either make no sense or only sense when a particular set up is found.
Independent of these specifics I guess you missed the main point of my post: There is no silver bullet. Obviously, microservices come with some drawbacks - so do microfrontends. But monoliths also come with drawbacks.
In other words:
Don't think in black and white. Choose what makes sense when it makes sense ...
If you're interested in Micro Frontends, I think you should check out Nuz!
Nuz is a fancy library to implements Micro Frontends compatible with ReactJS and may support more in the future. 🏃 Nuz is in beta! 🧪
Github github.com/lamhieu-vk/nuz
Great post Raymon!
Maybe you can include Piral in the list.
Hey Raymon, thanks for sharing, I am in the process of implementing micro frontends in my current company so I am gathering a lot of data right now. Thanks for the links.
Hi! Great article! You may also mention that Namecheap uses micro frontends with ESIs currently & recently we rolled out a solution for isomorphic micro frontends github.com/namecheap/ilc