Micro frontend architecture
Try to picture the following scenario: a medium to large, highly scalable front-end application with multiple development teams trying to work on its structure, demanding trivial patches and also implementing new features with a reasonably high frequency. To maintain the app and keep up with the pace, it is necessary to share responsibilities within the application among teams or even create new teams. How can we evolve the technology stack of such applications, in a non-obtrusive way? And how can we help to bring new developers into this process? The purpose of a micro frontend architecture is to solve questions like these.
The idea behind this article is to understand some of the main motivations for implementing a micro frontend architecture. In another moment we can go deeper and discuss advanced technical details.
Monolithic applications
A monolithic application is made of a complex codebase, centered around a single unity, that is, a single repository. There is no structural distinction between backend and frontend, and everything lives together in there. It may sound old-fashioned these days, and it is indeed. However, there was a time when this kind of structure was largely used, which is the reason why we have many legacy applications built like that.
There are some relevant problems related to this kind of structure:
- With a single codebase, complexity tends to increase exponentially on every new project iteration, either via a bugfix or a new feature. It is very likely that new developers joining the project will need more time and dedication to understand the entire project scope, which may harm the team's scalability.
- As code complexity and coupling increase among the application modules, there are more risks and difficulties in integrations and continuous integration/delivery (CI/CD), also demanding a higher level of coordination and communication to approach new features.
Microservices
As time went by, the concept of microservices was created. It helped improve the chaotic code scene found in monolithic applications. From that point on, we could have interdependent backend modules, with codebases stored in separate repositories.
With microservices, some of the backend code structuring problems were solved. However, we still had increasingly coupled frontend code and no technical evolution on the horizon. Then in 2016, ThoughtWorks’ Technology Radar mentioned micro frontend for the first time. The idea was to bring microservices concepts to the frontend world.
ASSESS — “We’ve seen significant benefit from introducing microservice architectures, which have allowed teams to scale delivery of independently deployed and maintained services. However, teams have often struggled to avoid the creation of front-end monoliths. We’re seeing an approach emerge that our teams call micro frontends.”
The biggest technical challenge was to split a monolithic frontend application into smaller, interdependent parts (micro applications) as it happened in the backend with microservices. But in a frontend application, some details made it harder to implement such concepts like shared state, the coexistence of multiple JavaScript frameworks/libraries on the same page, etc.
From that moment on, several experiments with different techniques and tools were created around the world. One of the used techniques was the implementation of micro applications using iframes, but its communication limitations with postMessage didn’t go that well in the context of web browser-based applications. One model that has been widely accepted for this type of architecture is the one base on web components, allowing micro applications to communicate with each other fluidly via events.
“In short, micro frontends are all about slicing up big and scary things into smaller, more manageable pieces, and then being explicit about the dependencies between them. Our technology choices, our codebases, our teams, and our release processes should all be able to operate and evolve independently of each other, without excessive coordination.”
Micro frontend principles
- Technology agnostic: every team must be able to choose and upgrade/update its technology stack independently.
- Microservice/business-oriented: each service code must be isolated and self-contained, with scope based on the business.
- Autonomous features: each micro application must be able to execute its responsibilities independently.
- Consistent UI/UX: the user experience must be completely transparent across micro applications.
Micro frontend benefits
- Decoupled, simplified codebases.
- Progressive enhancement (Strangler pattern).
- Independent deployments.
- Cohesive and autonomous teams
ADOPT — “Micro frontends have continued to gain in popularity since they were first introduced. We’ve seen many teams adopt some form of this architecture as a way to manage the complexity of multiple developers and teams contributing to the same user experience. We’re confident this style will grow in popularity as larger organizations try to decompose UI development across multiple teams.”
By implementing a micro frontend architecture there are several benefits: teams have greater delivery autonomy, with independent deployments (without needing to build the entire monolithic application); lower learning curve for new developers, for they will need to understand only the micro application context, resulting in faster onboarding; greater flexibility to evolve or even change the technology stack of a part of the application, among others.
However, we must take some precautions when working with such a structure. For instance, the user interface (UI) and user experience (UX) elements must be transparent in the end, that is, the user navigation and interaction must be consistent, regardless of the number of micro applications. Another important point is to guarantee performance when dealing with the same libraries (and versions) in different micro applications, for the application could load the same library multiple times.
Conclusion
It is very important to understand that a micro frontend architecture is not a silver bullet and we must take this approach with a grain of salt. Team size, application scalability, and business complexity, for instance, are variables that influence whether to implement micro frontends and must be taken into account before making a decision. In a future post, we can go over more technical aspects, including an example of such architecture.
References
https://thoughtworks.com/radar/techniques/micro-frontends
