How to Implement Micro-Frontend Architecture

Micro-frontends are not appropriate for every application. They are justified when multiple large teams own completely different sections of the product, when different sections need to be deployed independently without coordination, or when different parts of the application have fundamentally different technology requirements. For small teams or simple applications, the overhead of micro-frontend infrastructure far outweighs the benefits.

There are three primary integration approaches. Build-time integration means each micro-frontend is an npm package consumed by a shell app, which is simple but requires redeployment of the shell for any update. Server-side composition means the server assembles the final HTML from fragments delivered by different services. Runtime integration means micro-frontends are loaded in the browser as separate JavaScript bundles, which is the most flexible approach and is enabled by Webpack Module Federation.

Configure Module Federation in the Webpack config of each micro-frontend. Each app can act as a host that consumes remote modules, a remote that exposes modules, or both. In the remote's config, define which components or pages to expose. In the host's config, declare the remote URL and which modules to consume. At runtime, the host dynamically loads JavaScript chunks from the remote's deployed URL without any build-time dependency between them.

The shell is the container that loads and orchestrates all micro-frontends. It owns the global layout including the navigation bar and footer, handles authentication and provides the authenticated user to micro-frontends through a shared context, manages top-level routing deciding which micro-frontend to load for each URL, and provides shared infrastructure like error boundaries and loading states for each micro-frontend mounting point.

If each micro-frontend bundles its own copy of React, the user downloads React multiple times, wasting bandwidth. Configure shared dependencies in Module Federation so all micro-frontends use a single shared instance of heavy libraries like React, React DOM, and your design system. Define version requirements carefully. Incompatible version ranges force separate instances to load, which defeats the purpose of sharing and can cause React hook errors.

Micro-frontends must communicate without tight coupling. Use a shared event bus implemented as a simple pub-sub system on the window object or through a shared npm package. Micro-frontend A publishes an event with a payload. Micro-frontend B subscribes to that event name and reacts accordingly. Neither knows about the other directly. Custom browser events, a shared Redux store in the shell, or URL query parameters are all valid communication mechanisms depending on the complexity.

The primary benefit of micro-frontends is independent deployability. Each team can deploy their micro-frontend without coordinating with other teams. To make this safe, never make breaking changes to a shared interface without a deprecation period. Version your exposed module APIs. The shell must gracefully handle a micro-frontend being temporarily unavailable by showing a fallback UI instead of crashing the entire application.

Without coordination, each micro-frontend team will add dependencies that collectively bloat the user's download. Define and enforce a JavaScript bundle size budget for each micro-frontend. Include these budgets in CI pipelines so builds fail when a micro-frontend exceeds its allocation. Track the cumulative impact of all micro-frontends together as a portfolio metric to ensure the total user experience meets your performance goals.