How We Implemented Micro-Frontends at Choco
Vinicius Souza, Engineering Manager, explains what it is, why we adopted it, and how the team got it done.
Before we dive in, I’d like to share a quote from Luca Mezzalira, the author of I don't understand micro-frontends.
“Use the right tool for the right job, that should be our goal. Remember that developing software is empirical, not scientific.”
I’ll go even further and add that every decision we take architecture-wise will impact the organization as a whole. Therefore, the context of such a decision should be carefully taken into consideration.
Having an open mind and understanding that albeit Micro-frontends aren’t a silver bullet to every case you might stumble upon, you can truly benefit from this technique on a large and fast-paced scale.
Now, for those of you new to the Micro-frontends world, here’s a bit of background.
What the heck is Micro-frontends?
Micro-frontends are a technical representation of a user journey (business subdomain) owned by a squad. As such, they allow different technology choices, implementations, and independent iterations.
A non-focused team would deliver a user journey, get past it, and tackle the next one. Whereas a domain-focused team, besides being deeply knowledgeable on the subject, is always improving their user journey because they keep re-iterating it.
Predicting the change
Imagine the following scenario:
The startup you’ve been working for is growing at a fast pace. And guess what, your monolith is no longer an MVP. It is as though your product has made its way to the playoffs (to some extent). From now on, scaling up your product to keep up with the demand of a successful product is no longer an idea, but rather a reality that is going to be knocking on your door 24/7. Congrats, you’ve done it.
Understanding the problem
Backend folks are good at sniffing this problem from a mile away. They’ll start breaking down their monolith into separate services (Microservices) and scale up their system by using the strangler pattern.
On the other hand, on the Frontend side, things usually do not take this route, and we end up having a colossal monolith with no clear boundaries nor ownership of a user journey.
The problem comes to the surface when your organization starts facing these issues:
Communication overhead across the board for taking decisions (since everybody is working on the same codebase)
Sprint and deployment interdependency
No innovation of technology or processes, everything needs to be aligned and standardized across the board
Regression due to shared resources and wrong abstractions
Adopting it, detaching to see the bigger picture
First, you’ve got to understand that everything comes with a tradeoff. Adopting Micro-frontends will bring a lot of benefits and some other problems, and you’ll have to be ready to solve them. Be sure that the benefits outweigh the costs of such a decision within your team.
I genuinely believe that organizations can benefit from this technique, like Choco has, when:
Your company is using the Squad model, and you’re able to define business subdomains.
You want to avoid communication overhead across different teams and make them autonomous
You want to prevent sprint interdependency across the board
You want to deploy applications independently
In the next post, let’s dive in into tech choices and architecture.
Interested in joining our world-class front-end team at Choco? Diving into a big challenge? Check out our open roles here.