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:

---

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.

Communication Paths Between Teams Working on a Monolith Frontend

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.

Delivery Workflow: Monolith Frontend vs Micro Frontend

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.

Team Organization: Monolith Frontend vs Micro Frontend

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.

Micro Frontends in Spotify Web UI

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

Micro Frontend Authentication Workflow

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

Lifecycle of Shared Components in Micro Frontends

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.

Architecture Evolution

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?

Micro Frontend Implementation

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

Micro Frontend Deployment Pipeline

Also each Micro Frontend should get an independent deployment pipeline. Because it reduces the scope and the associated risk.

Micro Frontend Code Organization: Mono Repo vs Poly Repo

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:

• Luigi

• Single SPA

• Open Components

• Bit

• Frint.js

---

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.

---

Consider subscribing to get simplified case studies delivered straight to your inbox:

---

Follow me on LinkedIn and Twitter

---

Thank you for supporting this newsletter. You are now 14,371+ subscribers strong, very close to 14.5k. I think we can get to 14.5k subscribers by 16 November.

Consider sharing this post with your friends and get rewards. Y’all are the best.

---

How Discord Boosts Performance With Code-Splitting

Microservices Lessons From Netflix

---

• 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/