Micro Frontends

Concept#

Architectural Monolith vs Micro Frontends#

A frontend monolith is compiled and deployed as a single block of code. A change in the billing code requires building, testing, and releasing the entire application, creating a deployment bottleneck.

Micro Frontends split the frontend interface into distinct domains managed by independent teams. A main container (the App Shell) coordinates routing, global authentication, and lazy-loading of MFE domains:

                  ┌──────────────────────┐
                  │      App Shell       │
                  │  (Header, Auth, Nav) │
                  └──────────┬───────────┘
            ┌────────────────┼────────────────┐
            ▼                ▼                ▼
     ┌─────────────┐  ┌─────────────┐  ┌─────────────┐
     │  Auth MFE   │  │ Billing MFE │  │ Catalog MFE │
     │  (Team Red) │  │(Team Blue)  │  │(Team Yellow)│
     └─────────────┘  └─────────────┘  └─────────────┘

Routing & Viewport Orchestration#

The App Shell coordinates page routing. When the path shifts, it dynamically pulls the remote MFE container and mounts its root module:

Unsatisfied version: Shared module 'react' version 19.0.0 does not satisfy requiredVersion 18.2.0.

Communication Patterns between MFEs#

Micro Frontends must remain decoupled. Direct function calls or shared global Redux stores break isolation. Instead, use these patterns to communicate:

1. Custom Browser Events: MFEs dispatch standard browser events via window.dispatchEvent(new CustomEvent('cartUpdated', { detail: cart })).
2. Local Storage: Sharing credentials or session tokens via secure cookies or Web Storage.
3. URL Query Parameters: Passing simple states (e.g. ?searchQuery=react) during path navigation.

Common Mistakes#

1. Sharing a single global Redux store across MFEs#

Sharing one mutable state store couples MFEs tightly together. If Team Red modifies a reducer schema, Team Blue's MFE crashes. Each MFE must maintain its own isolated state store.

2. Duplicating CSS classes and styling libraries#

Loading multiple instances of Tailwind or CSS sheets in the same DOM view can lead to style conflicts. Solve this by namespace prefixes (e.g., prefixing classes with mfe-billing-) and sharing styling engines as singletons.

Best Practices#

• Build-Once, Run-Anywhere: MFEs should compile to static bundles that can run locally, in staging, and in production by fetching variables from runtime config objects.
• Isolate Styles: Use CSS Modules, styled-components, or strict prefix rules to prevent class bleeding across MFEs.
• Maintain a Component Sandbox: Ensure each team can run and develop their MFE independently in local mock sandboxes without loading other MFEs.