Micro-Frontend Architect

When to use

Use when a frontend application has grown too large for one team to own, when multiple teams need to ship independently, or when integrating applications from different frameworks. Trigger on phrases like "micro-frontend", "module federation", "frontend decomposition", or when a monolithic SPA has 500+ routes. Do not use for small apps or single-team projects — the overhead isn't justified.

Inputs to gather

• Team structure: how many teams, their ownership boundaries, release cadences
• Current architecture: monolith SPA, SSR app, static site — and the build system
• Shared state: global state (Redux, Zustand), URL state, server state (React Query)
• Framework homogeneity: all React, or mixed (React + Vue + Angular)?
• Deployment infrastructure: CDN, multiple origins, edge workers
• Performance constraints: initial load budget, shared dependency caching strategy

Procedure

1. Choose the integration pattern. Four main approaches:
   • Route-based splitting: each route is a separate bundle loaded on navigation. Simplest; use when teams own distinct pages.
   • Module Federation (Webpack 5+): runtime integration of separately built bundles. Best for sharing dependencies and lazy-loading remote modules. ModuleFederationPlugin exposes modules that other apps consume at runtime.
   • Build-time composition (Monorepo): packages built together but deployed independently. Best when teams share a monorepo with different deploy schedules.
   • iframe / server-side composition: each micro-frontend is fully isolated. Use for cross-framework or third-party integration. Most teams should start with route-based splitting and graduate to Module Federation only when they need runtime sharing.
2. Define shared dependencies. List every shared library (React, React DOM, design system, utility libraries) and decide: singleton (one instance — required for React), eager (load immediately), or version-matched. In Module Federation:

   shared: {
     react: { singleton: true, requiredVersion: '^18.0.0' },
     'react-dom': { singleton: true, requiredVersion: '^18.0.0' },
   }
   

   Mismatched React versions cause hooks to break — enforce singletons with version ranges.
3. Establish team boundaries. Each team owns: their routes/components, their build pipeline, their deployment, their runtime errors. Define a contract for cross-MFE communication: URL params for navigation, custom events for messaging, a shared API client for server state. Never share in-memory state across MFE boundaries — it couples teams.
4. Design the shell application. The shell (host) handles: global navigation, authentication/session, layout chrome (header/footer), and routing to micro-frontends. The shell must be lightweight (under 50KB gzipped) because it loads on every page. Micro-frontends register their routes with the shell lazily.
5. Plan for failure isolation. If one micro-frontend crashes, the shell and other MFEs must survive. Wrap each MFE in an Error Boundary that shows a fallback UI and reports the error. Never let a single team's bug take down the entire application.

Output format

An architecture document: integration pattern rationale, dependency sharing matrix, team boundary map, shell application spec, cross-MFE communication contract, and deployment topology.

Common pitfalls

• Over-sharing dependencies: sharing utility libraries causes version conflicts. Only share framework-level singletons.
• CSS leakage: styles from one MFE bleeding into another. Use CSS Modules, styled-components, or Shadow DOM for isolation.
• No error isolation: one MFE's crash takes down the page. Error boundaries are mandatory per MFE.
• Premature decomposition: micro-frontends add complexity (build orchestration, shared deps, deployment). Don't adopt until team scaling demands it.