Micro frontends: how many microservices is the magic number?
A tale of how technical design and internal buy-in must go hand in hand
“No more!” You cry out in frustration as your monolith of a web app fails another long build. You’ve waited so many minutes for your build and end-to-end tests to finish, and it is yet another failure over something ridiculous. “It’s time we break this into pieces,” you say. But how many is the right amount of micro frontends? Is there a magic number?
The answer is always, “there is no magic number.” In our particular scenario, we’ve chosen to use Module Federation for many reasons, the top two being UX and DX, as in developer experience.
As part of my role in our web infrastructure team, the project I was dealing with was a configuration app for an extremely powerful platform with infinite depth on many fronts. It had 45+ distinct pages, some with inner flows, some just the page content, and nothing more. My initial vision was one micro frontend per page. “Let’s break it into a thousand pieces!” I said enthusiastically. I suppose I had fallen in love with my newfound power of splitting and recombining apps at runtime.
Over time, we talked with the engineering teams who would inherit this new architecture. We explained the vision, and they expressed their concerns — they were mainly comprised of two kinds: one that we labeled “fear of change,” and we addressed those with adjusting the vision to be less of a revolution and more of a refinement of the way we build and deploy web apps. We don’t want engineers to have to relearn everything they know to be able to work on our project. The other kind was the more concrete fear that we were adding a lot of overhead to developing the app.
We gathered all the feedback on our technical design and went back to asking ourselves questions:
- Do we need to be able to build, test, and deploy each page independently?
- What is the purpose of dividing the app in the first place? What are our goals?
In breaking down the app, we wanted to — first and foremost — enable teams to independently build, test and deploy the parts of the system they own. Will they not be able to own their domains effectively if there is more than one page in these new apps? Perhaps we can bunch together pages that share data or functionality? These questions ignited a thought process.
We realized we could still achieve our goals of team independence, domain ownership, and faster build cycles by breaking down our beast of an app to pieces by domain. This division by domain, combined with our adjustments to lessen the learning curves for engineers, has allowed the teams to give up fear and look forward to our new architecture with confidence and hope.
