Discovering Micro-frontends
Micro-frontends: set the max-width of your website to 10px and you’re good right? WRONG.
Micro-frontends don’t actually have anything to do with the visual size of your frontend (neither are they related to the size in memory of your frontend’s codebase).
In this post I’ll be talking about the main concepts I learned while reading up on micro-frontends for the first time. My main sources were:
What are micro-frontends?
Another way to refer to micro-frontends is as “small independent frontends that can be composed into a larger frontend”, imagine putting a frontend in a frontend.
To get more technical, micro-frontends can be said to be:
“An architecture style where the codebase for a monolithic frontend application is replaced by smaller independent codebases. Each of these corresponding to an independently deliverable frontend application, or micro-frontend, which are then used to compose the final resulting frontend.”
There are various ways of deciding how to split a monolith into micro-frontends, for example you could make certain sections of a page their own micro-frontend or split the monolith by page.
Why micro-frontends?
Understanding why micro-frontends came to be doesn’t require too much effort if you consider why microservices came to be. Splitting a monolithic frontend into micro-frontends is similar to splitting a monolithic backend into microservices. Unsurprisingly, many of the benefits of microservices are shared by micro-frontends:
- More maintainable codebases: splitting a larger codebase into smaller independent parts makes it easier for developers to understand and work with a single part (granted that the original monolithic codebase was split in a logical and understandable manner).
- More scalable organization: you can assign independent and autonomous dev teams to each micro-frontend.
Each team is autonomous and in order to be autonomous a requirement is that each team should be organized “vertically”. That is to mean each team should be knowledgeable regarding the complete frontend stack. The opposite would be to organize teams horizontally, such as having one team handle all of the styling for the entire frontend.
In the case that each micro-frontend gets a corresponding backend microservice, teams could be even more vertical and include backend developers. - Easier to bring about incremental changes and be technology agnostic: thinking of trying out a new tool such as a new framework? Teams can evaluate and decide to integrate new tools independently of what other teams are using. The overall frontend will receive changes incrementally making it easier to gradually switch to a new framework compared to delaying doing so because refactoring the entire codebase would be too big of a chore.
- Independent deployment: instead of running many tests for a monolithic frontend, which may take time, each micro-frontend has its own independent CI/CD pipeline. As a benefit, if a micro-frontend suffers a catastrophic failure the other micro-frontends won’t be affected.
A key benefit I want to underline is the organizational aspect of micro-frontends: teams can make local decisions regarding their own part of the frontend as opposed to global decisions which in the case of a monolith would need to be discussed and coordinated with many more people.
A quick example
Imagine glassgate.com, a website where you can search and apply to jobs. This website has two micro-frontends, a “Browse Jobs” and an “Apply to Job” micro-frontend. Each micro-frontend has their own cross-functional and independent teams, respectively team A (red) and B (blue):
The key takeaways here are that:
- The final frontend is composed of individual frontends, each managed by cross-functional and independent teams.
- Teams are organized vertically and have complete autonomy over the decisions they make for their respective micro-frontends.
- Communication between micro-frontends must be well-thought, formalized, and respected by all teams.
Why not micro-frontends?
After reading a bit about what micro-frontends are and what benefits they can bring, I started looking at how to actually implement micro-frontends. It turns out that there are multiple architectures that support micro-frontends.
Complexity
In my personal opinion as a total micro-frontend newbie: my first impression regarding the implementation of micro-frontends is that doing so is complex. Especially compared to a component model.
In You probably don’t need a micro-frontend, Colin Eberhardt discusses why micro-frontends are probably not the best choice most of the time. You can read more about the reasons he says this but one reason I can’t argue too much with is the complexity that is brought into a project as a con to the benefits of micro-frontends.
Not for small projects/teams
In considering that one of the key benefits of micro-frontends are the organizational aspect, if the project is being built by a team of only a handful of developers with no immediate plans to scale the project, then micro-frontends might just introduce needless complexity.
In this cases it might be wise to start with a monolith for simplicity and if the need occurs there is always the option to start incrementally moving towards micro-frontends.
Conclusion
In I don’t understand micro-frontends, Luca Mezzarila addresses a discussion started by Dan Abramov questioning the concept of micro-frontends as opposed to a component model. I liked Luca’s main idea that one is not trying to replace the other, that the right tool should be chosen for the right job, and that that decision depends on the full context of the problems at hand.
That’s all I’ve got on micro-frontends for now, I’m curious as to how this architectural style will evolve in the future and what its use cases will be.