Everything You Need to Know About Micro Frontends
#21: Read Now - How 0.1% Companies Scale Development Teams (8 minutes)
Get the powerful template to approach system design for FREE on newsletter sign-up:
This post outlines how Micro Frontends work. If you want to learn more, scroll to the bottom and find the references.
Share this post & I'll send you some rewards for the referrals.
Frontend development is hard.
Scaling Frontend development on a large project with many teams is harder.
Image your business idea gets popular and you have many customers. You can split the backend into microservices for scalability.
But Frontend remains a complex monolith. So adding new features and technologies to Frontend becomes challenging.
Also it becomes difficult to scale development teams. Because the teams need to communicate with each other to make changes to the Frontend monolith. And it reduces their development speed.
So the development efficiency reduces as the number of teams grows due to many communication paths.
Besides it's likely that a new feature delivery needs a Frontend change. So the number of Frontend changes needed increases with many teams working on different backend microservices.
A simple solution to this problem is to split the teams to own both backend and Frontend services and distribute tasks fairly among them.
Also full rewrite of the Frontend is expensive. So it's important to support many tech stacks in Frontend from the beginning.
GreatFrontEnd (Featured)
Find top-quality front-end system design resources here on this end-to-end front-end interview preparation platform by ex-FAANG senior engineers.
Note: There are no affiliate links in this post.
What Is a Micro Frontend?
Micro Frontends are an extension of the microservices concept to the Frontend. It’s an architectural and organizational style.
Micro Frontend slices the website into self-contained, domain-driven micro apps. The micro apps then get built, tested, and deployed independently.
Micro Frontends are technology agnostic. So it can be implemented with different tools and frameworks like React, Vue, and Angular.
Also development teams should own a feature end-to-end: backend to the Micro Frontend. Because it would make them autonomous and efficient.
So teams should be formed around a business sub-domain instead of a specific technology.
Domain-driven design (DDD) is the key principle behind Micro Frontends. Put another way, each Micro Frontend represents a business sub-domain.
So boundaries of Micro Frontends should be set based on the value it provides to the users and not to the developers.
Besides bounded contexts in DDD make it harder for accidental coupling to occur. A bounded context is the boundary within a domain where a particular domain model applies.
The image shows how the Spotify Web UI looks with Micro Frontends.
How Does Micro Frontend Work?
The container application is the parent app that combines every Micro Frontend. It’s built with minimal HTML, CSS, and JavaScript.
The container application does the following:
Render common page elements like headers and footers
Render Micro Frontends on demand
Cross-cutting concerns like authentication and navigation
Here is how cross-cutting concerns work in Micro Frontends:
Micro Frontend Authentication
The container application interacts with the server to get an authentication token. The container application then injects the token into each Micro Frontend. The Micro Frontends sends the token with each request to the server.
Micro Frontend CSS Isolation
There is no namespacing or encapsulation in CSS. So there is a risk that styles might get overridden with Micro Frontends.
Some ways to prevent this problem are by using:
BEM CSS naming convention
SASS pre-processor
CSS modules
CSS-in-JS libraries
Micro Frontend Shared Components
A shared library offers visual consistency and code reuse in Micro Frontends.
Here is a simple approach to the development of shared components in Micro Frontends:
Allow teams to create their own components and duplicate code in the beginning.
Extract the code into a library when patterns emerge.
Yet it is important to avoid sharing business logic to prevent coupling.
Also a single team should own the shared component for high quality and consistency. But it should be kept open to contributions from every team.
Micro Frontend Testing
The test strategies are the same as with Monolithic Frontend. Each Micro Frontend needs automated tests.
But functional tests to check the correct assembly of the webpage must be kept minimal. Otherwise it increases complexity.
Micro Frontend Architecture
The 3 principles of Micro Frontend are:
Model around the business domain
Decentralization via autonomous teams
Automation culture for deployment
Each Micro Frontend gets deployed as an individual app. While DOM gets shared between Micro Frontends.
Micro Frontends are usually set up with the backend for frontend (BFF) pattern.
BFF pattern creates tailored backends for each Micro Frontend. But there is no need for a dedicated backend if the Micro Frontend consumes only a simple API.
Communication Between Micro Frontends
Micro Frontends shouldn't share their state but communicate via messages or events. Besides communication between Micro Frontends should be kept minimal to prevent coupling.
The ways Micro Frontends could communicate with each other are:
Custom events
Passing callbacks
Routing by using the address bar as a communication mechanism
Web workers
Consider subscribing to get the powerful system design template for FREE:
How to Implement Micro Frontend?
A separate server can be set up to render Micro Frontends. And a container app server can be installed to interact with relevant Micro Frontend servers on demand.
Some common anti-patterns in Micro Frontends are:
Not setting boundaries properly and creating many Micro Frontends
Increased complexity by using many frameworks and tools
Dependency hell in Micro Frontends
Also each Micro Frontend should get an independent deployment pipeline. Because it reduces the scope and the associated risk.
There are 2 ways to organize Micro Frontend code:
Monorepo
Polyrepo
A Monorepo uses a single repository to share code and libraries. It’s easier to track and manage. But there is a risk of accidental coupling if boundaries are not set correctly.
While a Polyrepo gives one repository per Micro Frontend. It keeps the code base independent. But it might become difficult to track and manage.
So there is no right or wrong approach but only the right way based on context.
There are 2 types of Micro Frontends based on composition: Build-time and Runtime.
Micro Frontend Build Time Integration
Micro Frontend gets published as a package. And container application includes it as a dependency.
But this approach creates coupling at the release stage. Put another way, a change in any Micro Frontend needs a release of every Micro Frontend.
So it's better to avoid build-time integration.
{
"name": "@frontend/container",
"version": "2.7.1",
"description": "A micro frontends app",
"dependencies": {
"@frontend/micro-app-1": "^3.1.9",
"@frontend/micro-app-2": "^8.2.1",
}
}Micro Frontend Runtime Integration
The composition occurs at runtime and the Micro Frontend can be updated on a browser refresh.
The different ways to set up runtime integration are:
iframes
JavaScript
Web Components
iframes
Building Micro Frontends with iframes is the simplest approach. It offers a good degree of isolation for styles and global variables.
But it might become less flexible and difficult to integrate. Also routing, history, and deep linking might get complicated.
<iframe id="micro-frontend"></iframe>JavaScript
The Micro Frontend gets added using <script> tag. It then exposes a global function as its entry point. The container application calls the global function of the Micro Frontend to render it.
This is probably the best way to do Micro Frontends because it’s flexible.
<script src="https://origin.server/micro-frontend.js"></script>Web Components
The Micro Frontend is defined as a custom HTML element. The container application then instantiates it.
This is a valid approach if you like the web components specification and want to use the browser capabilities.
But it may not be the right way if you want to define your own interface.
Micro Frontend Framework
Micro Frontends is still in its early stages of adoption. Yet some production-ready Micro Frontend frameworks exist:
Micro Frontend Advantages
The advantages of Micro Frontends are:
Fast delivery due to isolated deployments
Fast development cycle due to flexible tech stack and simple codebase
Improved maintainability and testability due to a small codebase
Scalable development due to autonomous teams
Low initial load time because Micro Frontends get loaded on demand
High reliability because modules are independent
A low entry barrier for new developers due to small codebase and bounded context
A decoupled system due to distributed architecture
Low coupling due to explicit data flow between different parts of the application
Easy rollback with a version switch
Faster product feedback via incremental upgrades on the parts of the app
Easy to update or rewrite parts of the Frontend
Easy to experiment with new technology in an isolated way
Micro Frontend Disadvantages
The disadvantages of Micro Frontends are:
Increased complexity due to operational overhead
Extra work to maintain a consistent user experience
High pushback from stakeholders to have visual consistency
Potential distributed monolith problem due to changing needs
Increased load time when the user navigates across the app. Because relevant Micro Frontend needs to be loaded
High bandwidth usage due to duplicate dependencies in Micro Frontends
Fragmented ways of work due to increased team autonomy
Increased operational and governance complexity due to many repositories, tools, and deployment pipelines
Takeaways
When to Use Micro Frontends
Micro Frontends are a good fit for:
Medium to large projects
Web projects
Productivity first projects that are tolerant to overheads
Projects with technical and organizational maturity
When Not to Use Micro Frontends
Micro Frontends are not a good fit if:
Small project
No bounded context is set to divide features among teams
Not enough automation is set up
Not comfortable with decentralized decisions around tooling and development practices
Micro Frontends are not a silver bullet. But Micro Frontends does solve problems in certain contexts.
Also single-page applications and server-side rendering remain valid options for the Frontend.
The benefits of Micro Frontends could outweigh the costs if risks are managed properly. So it’s important to do your own research.
👋 PS - Are you unhappy at your current job?
While preparing for system design interviews to get your dream job can be stressful.
Don't worry, I'm working on content to help you pass the system design interview. I'll make it easier - you spend only a few minutes each week to go from 0 to 1. Yet paid subscription fees will be higher than current pledge fees.
So pledge now to get access at a lower price.
“An easy-to-understand view of complex real-world architectures.” Fran
Consider subscribing to get simplified case studies delivered straight to your inbox:
Thank you for supporting this newsletter. Consider sharing this post with your friends and get rewards. Y’all are the best.
References
https://www.thoughtworks.com/radar/techniques/micro-frontends
https://martinfowler.com/articles/micro-frontends.html
https://www.infoq.com/presentations/evolution-micro-frontend/
https://www.altexsoft.com/blog/micro-frontend/
https://www.infoq.com/presentations/dazn-microfrontend/
https://www.aplyca.com/en/blog/micro-frontends-what-are-they-and-when-to-use-them
https://www.infoq.com/presentations/microfrontend-antipattern/
https://www.xenonstack.com/insights/micro-frontend-architecture
https://www.infoq.com/news/2018/08/experiences-micro-frontends/
https://aws.amazon.com/blogs/architecture/micro-frontend-architectures-on-aws/
Great break down of the topic.
I don't know much about frontend as I am a backend developer. But, learned a lot of new things from this!
I knew about Micro frontend however reading this makes things more concrete. Coincidently the question of micro frontend has been asked to me 2 times in different interviews after I read this. Thanks so much for this well written article :)