Module Federation Examples

The Modern.js Classic application is composed of several specialized packages:

• explore: Responsible for product exploration and database management.
• decide: Manages decision-making processes and user interactions.
• checkout: Handles the checkout process and order management.

This project demonstrates how Module Federation handles a host application (Shell) using React 18.2.0 for SSR, while consuming remotes running different React versions:

• Shell (Host): React v18.2.0 (includes SSR server).
• Remote1: React v16.6.3 (exposes Content component; consumes Image from Remote2).
• Remote2: React v17.0.2 (exposes Image component).

Runtime plugins allow you to move product policy out of the Module Federation core and into composable hooks. While the core runtime manages stable loading, sharing, snapshot, and factory execution, runtime plugins enable customization of:

• Request routing
• Fallback modules
• Share selection
• Resource loading
• Preload behavior
• Telemetry

This example demonstrates how to share a single stateful store across different frontend frameworks (React and Vue 3) using Module Federation.

Key components include:

• shell: A React-based host application that displays a counter based on the shared-store state.
• shared-store: A framework-agnostic store built with Effector that exposes the counter state.
• react-counter: A React remote component providing increment and decrement buttons.
• vue-counter: A Vue 3 remote component providing increment and decrement buttons.

This example demonstrates how to use two specific plugins within a Native Federation setup:

• native-federation-typescript
• native-fededration-tests

The architecture consists of two modules demonstrating these plugins in action:

• host
• remote

This example demonstrates how to share React Context values between a host application and a remote component using Module Federation.

Key components of this architecture:

• app1 (Host): The host application wrapped in a NameContextProvider with a specific value (e.g., "Billy").
• app2 (Remote): A standalone application that exposes a Welcome component. This component consumes the context provided by the host to render a message like "Welcome, <name>".
• shared-library: A shared library containing the NameContextProvider component used by both the host and the remote to ensure they are referencing the same context instance.

This example demonstrates how to federate both React components and Express routes between two separate servers using Module Federation.

Architecture Overview

• app1 (Host): An Express server rendering a React application. It consumes:
  • A federated component named Content from app2.
  • An API route /api/user that consumes a federated function from app2. This function is called with the request and response objects to return a response.
• app2 (Remote): An Express server that exposes:
  • A React component called Content (which supports dynamic props to demonstrate reactivity).
  • An Express route called userRoute.

This example demonstrates how to load nested remote components through multiple layers of Module Federation. The architecture follows this hierarchy:

1. app1 (Host): The main application that asynchronously loads ButtonContainer from app2.
2. app2 (Standalone Remote): A remote application that exposes the ButtonContainer component. This component, in turn, asynchronously loads Button from app3.
3. app3 (Standalone Remote): A remote application that exposes the Button component.

This implementation uses proprietary Software Streams to stream CommonJS modules at runtime to consuming applications. This enables Server-Side Rendering (SSR) for federated modules.

Capabilities:

• Supports import(), require, and import from (tested server-side; import() is tested on the client).
• Enables omnidirectional routing where pages or components can be federated between applications like a Single Page Application (SPA).

Security Warning: Currently, it is strongly suggested to only federate trusted software between servers, as the implementation is in beta and future features like stream encryption and WASM isolation are planned.

This example demonstrates a multi-layered Module Federation setup consisting of three distinct application types:

1. lib-app: A low-level application acting as a pure remote. It exposes foundational libraries such as react and react-dom.
2. component-app: A middle-level application that acts as both a host and a remote. It consumes react and react-dom from lib-app and exposes UI components like Dialog and Button to the main-app.
3. main-app: A top-level application acting as a pure host. It consumes modules from both lib-app and component-app.

Module Federation supports 'self-healing' when a remote application requires a shared dependency that the host application has not provided.

In this scenario, if a host (e.g., app1) defines a set of shared dependencies but omits one that a remote (e.g., app2) expects (such as styled-components), the runtime will automatically fetch the missing dependency from the remote application itself. This ensures the remote component still functions correctly without requiring the host to explicitly share it.

The playwright-e2e directory is organized as follows:

• common/: Contains reusable test helpers (e.g., base.ts, basePage.ts), selectors, and test fixtures.
• fixtures/: Contains shared test data such as constants.ts and commonTestData.ts.
• helpers/: Contains utility classes for data generation and file operations (e.g., base-helper.ts).
• types/: Contains shared enums and types (e.g., cssAttr.ts, requestsTypes.ts).
• results/: (Optional) Directory used by reporters to store test outputs.