Module Federation
#

Micro frontends↗ take the idea of microservices to frontend development. Instead of developing the application or a site as a monolith, the point is to split it as smaller portions programmed separately that are then tied together during runtime.

With the approach, you can use different technologies to develop other parts of the application and have separate teams developing them. The reasoning is that splitting up development this way avoids the maintenance costs associated with a traditional monolith.

As a side effect, it enables new types of collaboration between backend and frontend developers as they can focus on a specific slice of an application as a cohesive team. For example, you could have a team focusing only on the search functionality or other business-critical portion around a core feature.

Starting from webpack 5, there’s built-in functionality to develop micro frontends. Module federation and gives you enough functionality to tackle the workflow required by the micro frontend approach.

To learn more about module federation, see module federation examples↗ and Zack Jackson’s article about the topic↗.

Module federation example
#

To get started with module federation, let’s build a small application that we’ll then split into specific bundles loaded using the technique. The basic requirements of the application are as follows:

There should be a UI control with a list of items. Clicking on an item should show related information.
There should be a h1 with the application title.
From requirement 1., it follows that there should be a main section which will be connected to the control.

Above could be modeled as HTML markup along this:

<body>
  <h1>Demo</h1>
  <aside>
    <ul>
      <li><button>Hello world</button></li>
      <li><button>Hello federation</button></li>
      <li><button>Hello webpack</button></li>
    </ul>
  </aside>
  <main>
    The content should change based on what's clicked.
  </main>
</body>

The idea is that as any button is clicked, the content is updated to match the text.

To be semantically correct, you could wrap the h1 inside a header.

Adding webpack configuration
#

Set up webpack configuration for the project as follows:

webpack.mf.js

const path = require("path");
const { mode } = require("webpack-nano/argv");
const { merge } = require("webpack-merge");
const parts = require("./webpack.parts");

const commonConfig = merge([
  {
    entry: [path.join(__dirname, "src", "mf.js")],
    output: { publicPath: "/" },
  },
  parts.loadJavaScript(),
  parts.loadImages(),
  parts.page(),
  parts.extractCSS({ loaders: [parts.tailwind()] }),
]);

const configs = {
  development: merge(
    { entry: ["webpack-plugin-serve/client"] },
    parts.devServer()
  ),
  production: {},
};

module.exports = merge(commonConfig, configs[mode], { mode });

The configuration is a subset of what we’ve used in the book so far. It relies on the following .babelrc:

.babelrc

{
  "presets": [
    "@babel/preset-react",
    ["@babel/preset-env", { "modules": false }]
  ]
}

Set up npm scripts as follows:

package.json

{
  "scripts": {
    "build:mf": "wp --config webpack.mf.js --mode production",
    "start:mf": "wp --config webpack.mf.js --mode development"
  }
}

The idea is to have one script to run the project and one to build it.

If you want to improve the setup further, add Hot Module Replacement to it, as discussed in the related chapter.

If you haven’t completed the book examples, check out the demonstration from GitHub↗ to find the configuration.

Implementing the application with React
#

To avoid manual work with the DOM, we can use React to develop the application quickly. Make sure you have both react and react-dom installed.

src/mf.js

import ReactDOM from "react-dom";
import React from "react";
import "./main.css";

function App() {
  const options = ["Hello world", "Hello fed", "Hello webpack"];
  const [content, setContent] = React.useState("Changes on click.");

  return (
    <main className="max-w-md mx-auto space-y-8">
      <h1 className="text-xl">Demo</h1>
      <aside>
        <ul className="flex space-x-8">
          {options.map((option) => (
            <li key={option}>
              <button
                className="rounded bg-blue-500 text-white p-2"
                onClick={() => setContent(option)}
              >
                {option}
              </button>
            </li>
          ))}
        </ul>
      </aside>
      <article>{content}</article>
    </main>
  );
}

const container = document.createElement("div");
document.body.appendChild(container);
ReactDOM.render(<App />, container);

The styling portion uses Tailwind setup from the Eliminating Unused CSS chapter for styling so we can make the demonstration look better.

If you npm run start:mf, you should see the application running. In case you click on any of the buttons, the selection should change.

Separating bootstrap
#

The next step is breaking the monolith into separate modules. In practice, these portions can be different projects and developed in various technologies.

As a first step, we should use webpack’s ModuleFederationPlugin and load the application asynchronously. The change in loading is due to the way module federation works. As it’s a runtime operation, a small bootstrap is needed.

Add a bootstrap file to the project like this:

src/bootstrap.js

import("./mf");

It’s using the syntax you likely remember from the Code Splitting chapter. Although it feels trivial, we need to do this step as otherwise, the application would emit an error while loading with ModuleFederationPlugin.

To test the new bootstrap and the plugin, adjust webpack configuration as follows:

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

...

const commonConfig = merge([
  {
    entry: [path.join(__dirname, "src", "mf.js")],
    entry: [path.join(__dirname, "src", "bootstrap.js")],
    output: { publicPath: "/" },
  },
  ...
  {
    plugins: [
      new ModuleFederationPlugin({
        name: "app",
        remotes: {},
        shared: {
          react: { singleton: true },
          "react-dom": { singleton: true },
        },
      }),
    ],
  },
]);

...

If you run the application (npm run start:mf), it should still look the same.

In case you change the entry to point at the original file, you’ll receive an Uncaught Error: Shared module is not available for eager consumption error in the browser.

To get started, let’s split the header section of the application into a module of its own and load it during runtime through module federation.

Note the singleton bits in the code above. In this case, we’ll treat the current code as a host and mark react and react-dom as a singleton for each federated module to ensure each is using the same version to avoid problems with React rendering.

Separating header
#

Now we’re in a spot where we can begin breaking the monolith. Set up a file with the header code as follows:

src/header.js

import React from "react";

const Header = () => <h1 className="text-xl">Demo</h1>;

export default Header;

We should also alter the application to use the new component. We’ll go through a custom namespace, mf, which we’ll manage through module federation:

src/mf.js

...

import Header from "mf/header";

function App() {
  ...

  return (
    <main className="max-w-md mx-auto space-y-8">
      <h1 className="text-xl">Demo</h1>
      <Header />
      ...
    </main>
  );
}

Next, we should connect the federated module with our configuration. It’s here where things get more complicated as we have to either run webpack in multi-compiler mode (array of configurations) or compile modules separately. I’ve gone with the latter approach, as it works better with the current configuration.

It’s possible to make the setup work in a multi-compiler setup as well. In that case, you should either use webpack-dev-server or run webpack-plugin-serve in a server mode. See the full example↗ at their documentation.

To make the changes more manageable, we should define a configuration part encapsulating the module federation concern and then consume that:

webpack.parts.js

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

exports.federateModule = ({
  name,
  filename,
  exposes,
  remotes,
  shared,
}) => ({
  plugins: [
    new ModuleFederationPlugin({
      name,
      filename,
      exposes,
      remotes,
      shared,
    }),
  ],
});

The next step is more involved, as we’ll have to set up two builds. We’ll have to reuse the current target and pass --component parameter to it to define which one to compile. That gives enough flexibility for the project.

Change the webpack configuration as below:

webpack.mf.js

const { mode } = require("webpack-nano/argv");
const { ModuleFederationPlugin } = require("webpack").container;
const { component, mode } = require("webpack-nano/argv");

const commonConfig = merge([
  {
    entry: [path.join(__dirname, "src", "bootstrap.js")],
    output: { publicPath: "/" },
  }
  ...
  parts.extractCSS({ loaders: [parts.tailwind()] }),
  {
    plugins: [
      new ModuleFederationPlugin({
        name: "app",
        remotes: {},
        shared: {
          react: { singleton: true },
          "react-dom": { singleton: true },
        },
      }),
    ],
  },
]);

const shared = {
  react: { singleton: true },
  "react-dom": { singleton: true },
};
const componentConfigs = {
  app: merge(
    {
      entry: [path.join(__dirname, "src", "bootstrap.js")],
    },
    parts.page(),
    parts.federateModule({
      name: "app",
      remotes: { mf: "mf@/mf.js" },
      shared,
    })
  ),
  header: merge(
    {
      entry: [path.join(__dirname, "src", "header.js")],
    },
    parts.federateModule({
      name: "mf",
      filename: "mf.js",
      exposes: { "./header": "./src/header" },
      shared,
    })
  ),
};

if (!component) throw new Error("Missing component name");

module.exports = merge(commonConfig, configs[mode], { mode });
module.exports = merge(
  commonConfig,
  configs[mode],
  { mode },
  componentConfigs[component]
);

To test, compile the header component first using npm run build:mf -- --component header. Then, to run the built module against the shell, use npm run start:mf -- --component app.

If everything went well, you should still get the same outcome.

Pros and cons
#

You could say our build process is a notch more complex now, so what did we gain? Using the setup, we’ve essentially split our application into two parts that can be developed independently. The configuration doesn’t have to exist in the same repository, and the code could be created using different technologies.

Given module federation is a runtime process, it provides a degree of flexibility that would be hard to achieve otherwise. For example, you could run experiments and see what happens if a piece of functionality is replaced without rebuilding your entire project.

On a team level, the approach lets you have feature teams that work only a specific portion of the application. A monolith may still be a good option for a single developer unless you find the possibility to AB test and to defer compilation valuable.

Learn more
#

Consider the following resources to learn more:

Conclusion
#

Module federation, introduced in webpack 5, provides an infrastructure-level solution for developing micro frontends.

To recap:

Module federation is a tool-based implementation of micro frontend architecture
ModuleFederationPlugin is the technical implementation of the solution
When converting a project to use the plugin, set up an asynchronously loaded entry point
Using the approach brings complexity but at the same time allows you to split your project in ways not possible before

Module Federation #

Module federation example #

Adding webpack configuration #

Implementing the application with React #

Separating bootstrap #

Separating header #

Pros and cons #

Learn more #

Conclusion #

Comments#