What is a Micro frontend?

Micro frontends extend the concepts of microservices to the frontend world. They involve
breaking up a frontend monolith into smaller, more manageable pieces that can be developed,
tested, and deployed independently.

Key Concepts
1. Architecture

Monolithic vs. Micro frontend

 Monolithic Frontend: In a traditional monolithic frontend architecture, the entire user

interface is developed and deployed as a single unit. This can lead to several challenges:
o Scalability Issues: As the application grows, it becomes harder to manage, scale,
and deploy.
o Collaboration Challenges: Multiple teams working on the same codebase can
lead to merge conflicts and slower development cycles.
o Slower Deployment: Any change, no matter how small, requires redeploying the
entire application.
 Micro frontend Architecture: Micro frontends address these issues by breaking the
monolithic frontend into smaller, self-contained units, each responsible for a specific part
of the application. Each micro frontend can be developed, tested, and deployed
independently.
o Scalability: Each micro frontend can be scaled independently based on its needs.
o Autonomy: Teams can work on different micro frontends without interfering
with each other.
o Faster Deployment: Changes can be deployed more frequently as each micro
frontend is deployed independently.

Example: Imagine an e-commerce website with the following sections:

 Header
 Product Listing
 Shopping Cart
 User Profile

In a monolithic architecture, all these sections are part of a single codebase and deployed
together. In a micro frontend architecture, each section can be a separate micro frontend:

 Header Micro frontend: Responsible for the navigation bar and logo.
 Product Listing Micro frontend: Manages the display of products.
 Shopping Cart Micro frontend: Handles the shopping cart functionality.
 User Profile Micro frontend: Manages user information and settings.
Module Federation

Module Federation is a feature in Webpack 5 that allows multiple independently built and
deployed micro frontends to coexist and share code seamlessly. This is particularly useful for
micro frontend architectures.

Key Features:

 Dynamic Imports: Micro frontends can dynamically load each other’s code at runtime.
 Shared Libraries: Common libraries (e.g., React, Lodash) can be shared between micro
frontends to avoid duplication and reduce bundle size.
 Remote Modules: Each micro frontend can expose parts of its codebase to be consumed
by others.

Using micro frontends with Module Federation enables a highly modular and scalable
architecture where teams can work independently while sharing common functionalities.

2. Decomposition Strategies

Decomposing a frontend monolith into micro frontends involves breaking down the application
into smaller, self-contained units. There are two primary strategies for this decomposition: route-
based and component-based.

Route-based Decomposition

In route-based decomposition, each micro frontend is responsible for a specific route or set of
routes in the application. This approach is often used when different parts of the application can
be clearly separated by their URLs.

Example: Consider a web application with the following routes:

 /home
 /products
 /cart
 /profile

Each route can be handled by a different micro frontend:

The main application’s router can dynamically load the appropriate micro frontend based on the
current route.
Component-based Decomposition

In component-based decomposition, each micro frontend is responsible for a specific component

or set of components within a single route. This approach is useful when different parts of the
same page can be developed and deployed independently.

Example: Consider a dashboard page with the following components:

 Header
 Sidebar
 Main Content
 Footer

Each component can be handled by a different micro frontend.

When to Use Each Strategy

 Route-based Decomposition: Best suited for applications with clear, distinct sections
that can be separated by URLs. Examples include multi-page applications like e-
commerce sites or admin dashboards.
 Component-based Decomposition: Ideal for single-page applications or pages with
complex layouts where different components can be developed and deployed
independently. Examples include dynamic dashboards or content-heavy pages.

3. Integration Methods

Integrating micro frontends involves combining these independently developed and deployed
units into a cohesive user interface. There are two primary methods for integrating micro
frontends: client-side integration and server-side integration.

Client-side Integration

Client-side integration means combining micro frontends directly in the browser. This method
uses JavaScript to dynamically load and render micro frontends based on user interactions or
route changes.

Advantages:

 Flexibility: Micro frontends can be loaded and unloaded dynamically based on user
interactions.
 Independence: Each micro frontend can be developed and deployed independently.

Disadvantages:
  Performance: Can increase initial load time and client-side processing overhead.
 Complexity: Requires careful management of dependencies and global state.

Server-side Integration

Server-side integration means combining micro frontends on the server before sending the
response to the client. This method assembles the micro frontends into a single HTML
document, which is then sent to the browser.

Advantages:

 Performance: Faster initial load time since the assembled HTML is sent directly to the
client.
 SEO: Better for search engine optimization as the HTML is fully rendered on the server.
 Consistency: Easier to ensure a consistent look and feel across micro frontends.

Disadvantages:

 Flexibility: Less dynamic compared to client-side integration.

 Deployment Coordination: Requires coordination between server and micro frontend
deployments.

When to Use Each Method

 Client-side Integration: Suitable for applications that require dynamic loading of

components, such as Single Page Applications (SPAs) or applications with frequent user
interactions.
 Server-side Integration: Ideal for content-heavy sites that benefit from faster initial load
times and better SEO, such as news websites or blogs.

4. Communication

In a micro frontend architecture, different micro frontends need to communicate with each other
to provide a cohesive user experience. This communication can be challenging because each
micro frontend is designed to be independent and self-contained. Here are the primary methods
of communication between micro frontends:
Shared State

Sharing state between micro frontends can be complex but is sometimes necessary to ensure a
consistent user experience.

Techniques:

1. Global State Management: Using a state management library (like Redux) to create a
global store that all micro frontends can access.

2. Custom Events: Using the browser's built-in Custom Event API to emit and listen for
events.

Events and APIs

1. REST or GraphQL APIs: Using APIs to fetch and share data between micro frontends.

2. Shared Services: Creating a shared service that can be used by multiple micro frontends
to manage common functionality.

When to Use Each Method

 Shared State: Best for applications where multiple micro frontends need to share and
update the same state frequently. Requires careful management to avoid state conflicts
and ensure consistency.
 Events and APIs: Suitable for loosely coupled micro frontends where direct
communication is less frequent. Custom events are ideal for simple, one-way
communication, while APIs are better for more complex data sharing.

5. Deployment

Deployment of micro frontends involves independently deploying each micro frontend while
ensuring they all integrate seamlessly in the production environment. This approach allows
teams to deploy updates to specific parts of the application without affecting the entire system,
leading to faster release cycles and more resilient systems.

Key Considerations for Deployment

1. Independent Deployment:
 o Each micro frontend should be deployed independently, allowing teams to
update and release changes without impacting other parts of the application.
o This requires a CI/CD pipeline for each micro frontend to automate the build,
test, and deployment processes.
2. Versioning:
o Proper versioning strategies are crucial to manage compatibility between micro
frontends.
o Semantic versioning can be used to ensure that updates to one micro frontend
do not break dependencies in others.
3. Isolation:
o Each micro frontend should run in isolation to prevent conflicts, especially with
shared resources such as CSS, JavaScript libraries, and state.
o Techniques like CSS Modules, shadow DOM, or scoped styles can help achieve
isolation.

Deployment Techniques

1. Static Asset Deployment:

o Micro frontends are built into static assets (HTML, CSS, JS) and deployed to a
content delivery network (CDN) or static hosting service.
o URLs of these assets are used to integrate microfrontends into the main
application.

2. Containerization:

 Microfrontends can be containerized using Docker, allowing them to be deployed as

independent services.
 Container orchestration tools like Kubernetes can manage the deployment, scaling, and
monitoring of these containers.

3. Module Federation:

 Webpack's Module Federation allows microfrontends to dynamically load code from

other microfrontends at runtime.
 This technique is particularly useful for sharing code and dependencies between
microfrontends.

When to Use Each Technique

 Static Asset Deployment: Ideal for simple applications where microfrontends are
essentially static files served over a CDN.
 Containerization: Suitable for more complex applications requiring isolation and
scalability, often used in microservices architecture.
 Module Federation: Useful for applications requiring dynamic loading of microfrontends
and sharing of code or dependencies.