Module Federation

Unlike traditional build-time dependency management, Module Federation allows a host application to dynamically fetch and execute code from a remote application at runtime. This eliminates the need to redeploy the entire application when a single micro-frontend updates. The remote exposes modules via a ModuleFederationPlugin configuration, and the host consumes them asynchronously using standard import() syntax. This mechanism supports lazy loading, ensuring that code is only fetched when a user navigates to a specific feature, drastically improving initial load performance.

A core challenge in micro-frontend architectures is avoiding loading multiple copies of heavy libraries like React or lodash. Module Federation solves this through a sophisticated shared dependency negotiation. When a remote module loads, it checks the host's shared scope for a compatible version of a required dependency. If a sufficient version exists, the remote uses the host's instance instead of loading its own. This is configured via the shared option in the Webpack plugin, where libraries can be marked as singleton to enforce a single instance across the entire application graph, preventing runtime errors and reducing bundle bloat.

Module Federation decouples the deployment pipelines of different teams. A team owning a remote application can build, test, and deploy their micro-frontend independently, without coordinating with the host application team. The host dynamically fetches the latest version of the remote's entry point at runtime. This enables continuous delivery for distributed frontend teams. Version mismatches are managed through semantic versioning checks in the shared dependency configuration, allowing teams to safely roll back a remote without breaking the host or other remotes that depend on a different version of a shared library.

Module Federation is not limited to a strict host-consumer hierarchy. It supports bidirectional sharing, where a host can expose its own modules to remotes, and remotes can expose modules to each other. This creates a flexible, graph-based architecture. For example, a host shell application can expose a global authentication service or a design system component library that all remotes consume. Simultaneously, a remote checkout application can expose its order summary widget to a remote analytics dashboard. This pattern enables true composability at the architectural level.

A specialized pattern where a dedicated remote application is built solely to expose shared vendor libraries, such as React, React-DOM, and Moment.js. This 'vendor remote' is deployed to a persistent URL and acts as a centralized dependency store. All other host and remote applications configure this vendor remote as a shared source. This strategy guarantees that every micro-frontend in the ecosystem uses the exact same physical build artifact for a given library, eliminating the risk of subtle bugs caused by duplicated or slightly different library instances, and centralizing the update process for critical third-party code.

To prevent a runtime error in one remote micro-frontend from crashing the entire host application, Module Federation is typically paired with React Error Boundaries or equivalent framework-level error handling. When a remote module fails to load due to a network issue, a JavaScript exception, or a deployment mismatch, the error boundary catches the failure and renders a graceful fallback UI. This ensures fault isolation, maintaining a functional user experience even when a non-critical remote service is degraded. The host can also implement retry logic for fetching remote entry points to handle transient network failures.

The most common pattern where a Shell Application (or host) acts as the primary layout and routing engine, dynamically fetching Micro-Frontend Slices from different team-owned deployments at runtime.

• Independent Deployments: Team A can deploy a new product detail page without rebuilding Team B's checkout flow.
• Shared User Context: The shell shares authentication state and routing parameters with all federated modules.
• Example: An e-commerce site where the header, product grid, and cart are separate federated applications composed into a single view.

Federate tenant-specific customizations without forking the core application codebase. The base platform provides the core logic, while tenant-specific modules override or extend functionality at runtime.

• White-Labeling: Each client loads a custom theme, navigation, or business logic module without exposing other tenants' code.
• Versioned APIs: The host can load different module versions for different tenants, enabling staggered rollouts.
• Isolation: A bug in a tenant's custom reporting module cannot crash the core authentication service.

Module Federation is not limited to the browser. By federating Node.js modules, you can compose micro-frontends on the server to deliver fully rendered HTML, solving the SEO and initial load challenges of client-side composition.

• Streaming SSR: Federated components render in parallel on the server and stream to the client as they complete.
• Unified Data Fetching: The host orchestrates server-side data requirements for all federated fragments in a single request waterfall.
• Example: A content-heavy media site where the article body, comments section, and sidebar are federated modules rendered server-side for optimal Core Web Vitals.

A critical use case is the de-duplication of vendor libraries like React, lodash, or a design system. Module Federation allows hosts and remotes to negotiate shared singleton dependencies to prevent loading multiple copies.

• Singleton Enforcement: The shared configuration ensures only one instance of React runs, preventing hooks context errors.
• Version Negotiation: Semantic version ranges allow a remote to fall back to its own copy if the host's version is incompatible.
• Performance Impact: Prevents shipping duplicate 40kB+ libraries, drastically reducing total JavaScript parse time.

Module Federation enables branch-based deployments where a pull request automatically deploys a new version of a single micro-frontend to a unique URL. Reviewers can then test the new module in the context of the production shell.

• Ephemeral Environments: Each feature branch gets a live URL that integrates with the production host, enabling full end-to-end testing without staging infrastructure.
• Dynamic Remotes: The host can be configured to load a remote from a specific preview URL based on a query parameter or cookie.
• Example: A design system team publishes a preview of a new button component, and stakeholders review it live inside the main application before merging.

Use Module Federation as a strangler fig pattern to incrementally migrate from a legacy monolithic frontend to a modern stack without a full rewrite or feature freeze.

• Side-by-Side Execution: A legacy AngularJS shell can federate in new React or Vue components for new features.
• Route-Level Migration: One route at a time is replaced by a federated modern module while the rest of the app remains untouched.
• Risk Mitigation: If the new federated module fails, the legacy version remains untouched, allowing for instant rollback.