Micro Frontends Architecture with Module Federation · Lesson

Sharing Modules & Components

Learn to expose components from a remote application and consume them in a host application.

Sharing Modules & Components is a free Micro Frontends Architecture with Module Federation lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Micro Frontends Architecture with Module Federation learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Intro to Module Sharing

In this lesson, we'll dive into the heart of Micro Frontends: sharing code!

We'll learn how one application can "expose" its components or modules, and how another application can "consume" them. This is key to building truly independent yet collaborative federated apps.

Understanding Exposed Modules

An exposed module is a piece of code (like a React component, a utility function, or even a data store) that one Micro Frontend application decides to make available to other applications.

Think of it like publishing a library.
The application making it available is called the Remote Application.
It's configured within the Remote's Webpack setup.

How a Remote Exposes

To expose a module, you configure the ModuleFederationPlugin in your remote application's webpack.config.js. The exposes property is where the magic happens.

You define a public name for the module and point it to its local path.

const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  // ... other webpack config ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'remoteApp',
      filename: 'remoteEntry.js',
      exposes: {
        './Button': './src/components/Button.jsx',
        './Header': './src/components/Header.jsx'
      },
      shared: ['react', 'react-dom']
    })
  ]
};

Example: Our Shared Button

Let's imagine a simple React button component that our remote application wants to share. This component lives in ./src/components/Button.jsx.

It's just a regular React component until we expose it.

// src/components/Button.jsx
import React from 'react';

const Button = ({ onClick, children }) => {
  return (
    <button
      onClick={onClick}
      style={{
        padding: '10px 20px',
        backgroundColor: '#007bff',
        color: 'white',
        border: 'none',
        borderRadius: '5px',
        cursor: 'pointer'
      }}
    >
      {children}
    </button>
  );
};

export default Button;

Consuming Remote Modules

On the flip side, a remote module is a module that an application wants to use, but it's hosted by another federated application.

The application consuming it is called the Host Application.
The Host needs to know where to find the Remote Application's exposed modules.

How a Host Consumes

The host application also uses the ModuleFederationPlugin. Here, you define the remotes property, mapping a local alias to the remote application's entry point.

The entry point is typically remoteEntry.js, generated by the remote app's Webpack build.

const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  // ... other webpack config ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'hostApp',
      remotes: {
        remoteApp: 'remoteApp@http://localhost:3001/remoteEntry.js'
      },
      shared: ['react', 'react-dom']
    })
  ]
};

Importing & Using Shared Components

Once configured, the host application can import the remote component as if it were a local module. Webpack (via Module Federation) handles the dynamic loading from the remote URL.

Try running this simple example:

// This simulates a host app importing a remote component.
// In a real setup, 'remoteApp/Button' would resolve to the
// component exposed by the 'remoteApp' through Module Federation.
import React from 'react';
import ReactDOM from 'react-dom/client';

// Imagine 'remoteApp/Button' is the component we exposed earlier
// This import is resolved by Webpack's Module Federation Plugin
const RemoteButton = React.lazy(() => import('remoteApp/Button'));

function App() {
  return (
    <div>
      <h1>Host Application</h1>
      <React.Suspense fallback={<div>Loading Remote Button...</div>}>
        <RemoteButton onClick={() => alert('Button Clicked!')}>
          Click Me From Remote!
        </RemoteButton>
      </React.Suspense>
    </div>
  );
}

// Full entry point for a runnable React app
const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(<App />);

Behind the Scenes: Dynamic Loading

When the host application tries to import remoteApp/Button, Webpack doesn't look for it in the local node_modules. Instead, it uses the remotes configuration to:

Fetch the remoteEntry.js from the specified URL.
Load the exposed Button module from within that remote entry.
This happens dynamically at runtime, allowing independent deployments!

Best Practices for Sharing

When defining your exposes and remotes, keep these tips in mind:

Clear Naming: Use descriptive names for your exposed modules (e.g., ./UserProfileCard).
Consistent Aliases: Ensure your remote aliases in the host are easy to understand (e.g., marketingApp).
Relative Paths: Use relative paths (./src/...) for exposed modules within the remote app.

Test Your Understanding

You've learned how to expose and consume modules. Let's check your understanding of the core configuration!

Lesson Summary & Next Steps

Great job! You've learned the fundamental mechanics of sharing modules with Webpack Module Federation:

Exposing: Remote apps use exposes to make components public.
Consuming: Host apps use remotes to import and use those components.
This dynamic loading allows for independent development and deployment.

Next, we'll build a simple federated application from scratch, putting these concepts into practice!

Frequently asked questions

Is the “Sharing Modules & Components” lesson free?

Yes — the full text of “Sharing Modules & Components” is free to read here on the web, and the Micro Frontends Architecture with Module Federation course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Micro Frontends Architecture with Module Federation course, upgrade to CoddyKit PRO.

What will I learn in “Sharing Modules & Components”?

Learn to expose components from a remote application and consume them in a host application. You practise Micro Frontends Architecture with Module Federation with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Micro Frontends Architecture with Module Federation?

No prior experience is required. Micro Frontends Architecture with Module Federation on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Sharing Modules & Components” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Micro Frontends Architecture with Module Federation lesson?

Yes. Every Micro Frontends Architecture with Module Federation lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

Project Setup & Configuration
Sharing Modules & Components
Building a Simple Federated App
Running and Debugging Your Federated App Locally

← Back to Micro Frontends Architecture with Module Federation