Micro frontends also allow large teams to share common components – such as headers, footers, and logins – across multiple applications, ensuring consistency and keeping their projects DRY (Don’t Repeat Yourself).

In this article, you will learn:

• How to set up a project and folder structure that implements a Micro Frontend (MFE) Infrastructure

• How to use and configure the @originjs/vite-plugin-federation to allow Module Federation (MF) usage with Vite projects.

• How to share and consume React components between apps.

• How to run and test your app with shared components locally

Table of Contents

• Pre-Requisites

• What Is Module Federation?

• Benefits of Module Federation

• Project Structure

• How to Create the Projects

• How to Install Dependencies

• How to Configure the Remote App

• The Vite Module Federation Plugin

• Key Constraints On Exported Modules

• How to Create the Remote Components

• How to Consume the Remote Components Within the Host

• How to Handle TypeScript Errors

• How to Add RemoteWrapperComponent to App.tsx

• How to Serve the Remote App and Run Your Host

• The True Power of Micro Frontends

• Final Thoughts

Pre-Requisites

• Node installed on your machine – you can get your download of Node here

• Familiarity with JS / TS and React

• Familiarity with Command Line / Terminal

What Is Module Federation?

Before we go any further, let’s talk about Module Federation (MF).

Module Federation is a technique in web development that allows multiple separate builds to work together as a single application. It enables the sharing of code between different, independent applications at runtime, rather than at build time. This means a host application can dynamically load and execute code from a remote application.

At its core, Module Federation uses a "host" and "remote" architecture. A host application is the main app that consumes shared code / components. A remote application is the one that exposes code to be consumed.

The remote app specifies which parts of its code, or "modules," are available for others to use. The host then references these modules and loads them as needed.

Benefits of Module Federation

Independent Deployment

Module Federation lets teams build and deploy their micro-frontends separately. This eliminates the need for full application redeployments, accelerating development and reducing risk.

Efficient Code Sharing

MF provides a native way to share code and dependencies between micro-frontends. This prevents code duplication, reducing bloat and ensuring consistency.

Performance Gains

By sharing dependencies, Module Federation reduces the overall bundle size and improves initial load times, as each micro-frontend doesn't download its own copy of common libraries.

Scalability and Maintainability

MF enables a scalable architecture by breaking down large applications into smaller, manageable micro-frontends. This makes the codebase easier to maintain and allows teams to work independently.

Analogy

Imagine building an online store. Traditionally, you’d create the entire site – homepage, product pages, cart, user profile – as one big application. A small cart change would require rebuilding and redeploying everything.

With Micro Frontends and Module Federation, the shopping cart can be its own app, built and maintained by a dedicated team. The main site simply imports it, allowing the cart team to release updates independently, speeding up development and improving focus.

This also works for organisations with multiple sites that need a consistent look. Shared components like a header, footer, or product card can be reused across sites with different purposes, such as hiring vehicles or selling furniture, ensuring visual consistency while keeping functionality unique.

Project Structure

You will need to create two projects:

• host – this will act as your host application

• remote – this will expose the components you want to share

How to Create the Projects

Run the following commands in your terminal to create your root project folder and your two Vite projects:

# create micro-frontends directory for two vite projects, and navigate to folder
mkdir micro-frontends; cd micro-frontends

Create a Git Repository (Optional)

Using the below command you can create a Git repository for source control.

# initiate git repo
git init

# create host application vite app
npm create vite@latest host-app

# once submitted the command, select React and press Enter, 
Select a framework:
│  ○ Vanilla
│  ○ Vue
│  ● React
│  ○ Preact
│  ○ Lit
│  ○ Svelte
│  ○ Solid
│  ○ Qwik
│  ○ Angular
│  ○ Marko
│  ○ Others

# select Typescript + SWC and again press Enter
Select a variant:
│  ○ TypeScript
│  ● TypeScript + SWC
│  ○ JavaScript
│  ○ JavaScript + SWC
│  ○ React Router v7 
│  ○ TanStack Router
│  ○ RedwoodSDK 
│  ○ RSC

Once this is done, navigate back to the root project folder (micro-frontends):

# navigate back
cd ../

# create remote-app 
npm create vite@latest remote-app

# follow instructions as before to select React, Typescript + SWC

You now have your two projects, host-app and remote-app.

How to Install Dependencies

Open the micro-frontends folder in your preferred IDE / Code Editor. In this tutorial I’ll be using VS Code.

Tip: You can open the current folder in VS Code via your terminal using the following command code . if you’ve already added code to you PATH.

Once you’ve opened VS Code, open the terminal and run the following command:

cd host-app && npm install -D @originjs/vite-plugin-federation

and then run:

cd ../remote-app && npm install -D @originjs/vite-plugin-federation

Styling

To see styling like my examples, you need to add Tailwind CSS to both your remote and host applications. You can find instructions on how to do so here

How to Configure the Remote App

In order to be able to utilise modules and components from your remote applications, you need to configure your application to expose those modules, and your host app to consume them.

Use the following configurations in your apps to allow your components to be exposed and consumed – don’t worry about the components just yet, you’ll create them soon.

Host App – Vite.config.ts

In the host app, open vite.config.js and add the following configuration:

//host - vote.config.js
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react-swc";
import federation from "@originjs/vite-plugin-federation";


export default defineConfig({
  plugins: [
    react(),
    federation({
      name: "host_app",
      remotes: {
        remote_app: "http://localhost:5001/assets/remoteEntry.js",
      },
      shared: ["react", "react-dom"],
    }),
  ],
  build: {
    modulePreload: false,
    target: "esnext",
    minify: false,
    cssCodeSplit: false,
  },
});

Remote App – Vite.config.ts

In the remote app, open vite.config.js and add the following configuration:

// remote - vite.config.js
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react-swc";
import federation from "@originjs/vite-plugin-federation";

export default defineConfig({
  plugins: [
    react(),
    federation({
      name: "remote_app",
      filename: "remoteEntry.js",
      exposes: {
        "./Button": "./src/components/Button",
        "./Header": "./src/components/Header",
      },
      shared: ["react", "react-dom"],
    }),
  ],
  build: {
    modulePreload: false,
    target: "esnext",
    minify: false,
    cssCodeSplit: false,
  },
  preview: {
    port: 5001,
    strictPort: true,
    cors: true,
  },
});

Explanation of Vite Configuration:

1. plugins: array where you tell Vite which plugins to use when it:

• Runs your dev server

• Builds your production bundle

Each plugin is basically a little (or big) piece of code that hooks into Vite’s build pipeline to add extra features – for example:

• Adding React JSX/TSX support (@vitejs/plugin-react)

• Enabling Module Federation (@originjs/vite-plugin-federation)

2. build: Controls how Vite produces the production build. You don’t need to worry too much about this for the purpose of this tutorial.

3. preview: Controls how the application is served / previewed:

• Useful in microfrontend setups where a fixed port and CORS enabled are needed so other apps can fetch your remote modules.

• strictPort: true ensures predictable networking – avoids “it works on my machine” issues with random ports.

The Vite Module Federation Plugin

You need to configure your Vite Module Federation plugin to inform it what components are to be consumed and exposed. Let’s take a look at the configured properties:

• name: The unique identifier for your remote application in a Module Federation setup. This is the name other applications (hosts) will use when they declare your app as a remote.

• filename: This is the name of the file that your host will load when it tries to retrieve your exposed modules.

• exposes: A mapping of public module names → local file paths. This is how you decide which parts of your code are available to be consumed remotely.

exposes: {
  "./Button": "./src/components/Button",
  "./Header": "./src/components/Header"
}

The key ("./Button") is the public module name – the name that other apps (the host) will use when importing the module from your remote.

How It Works:

• Key ("./Button") is the exposed identifier other apps can request.

• Value ("./src/components/Button") is the actual file path inside your project.

For example, if your remote’s name is "remote_app", the host can import like this:

import Button from "remote_app/Button";

Under the hood, "remote_app" matches the remote’s name in its federation() config and Button matches the "./Button" key in exposes.

• shared: dependencies that should be shared between the host and remote. It avoids shipping duplicate copies of large libraries (like React), ensuring the host and remote use the same instance – you can read more here about the possible configurations.

• remotes: A mapping of remote app names → the URL to their remoteEntry.js file. This tells the host where to fetch the exposed modules at runtime.

remotes: { remote_app: "http://localhost:5001/assets/remoteEntry.js" }

The key remote_app must match the name in the remote’s config.

The value is the full URL to the remote’s entry file (served in dev or deployed in prod). Remember we set strictPort:true earlier – this is why. We need to ensure we’re pointing at the correct domain & port.

Key Constraints On Exported Modules

Naming constraints and rules

The key in exposes ("./Button"):

• Must start with ./ (per Module Federation spec).

• Must be unique within the remote.

• Is case-sensitive.

• This is the public module path the host will request.

• Doesn’t have to match the filename, but matching is a good convention for ease of reading

The file you point to ("./src/components/Button"):

• Can export default, named exports, or both.

• The host can import default or named exports, same as any ES module:

    // Default export
    import MyButton from 'remote_app/Button';
  
    // Named export
    import { SpecialButton } from 'remote_app/Button';
  

The import name:

• Completely up to the host developer when importing a default export.

• Must match exactly for named exports.

How to Create the Remote Components

Ok, so you’ve created your project structure, and you’ve setup your vite.config.ts file to allow for exposing and consuming your shared assets. Next you will create the remote components.

Button Component

Let’s say you want to create a button component which will be shared across all your host applications, as you want to keep consistency. You can do this as below:

Navigate to the remote-app folder and create a new file called Button.tsx in src/components this will ensure it matches the configured federation plugin.

// remote - ./src/components/Button.tsx
import React from "react";

interface ButtonProps {
  text: string;
  onClick?: () => void;
}

const Button: React.FC<ButtonProps> = ({ text, onClick }) => {
  return (
    <button
      onClick={onClick}
      className="px-4 py-2 bg-green-500 text-white rounded hover:bg-green-600 hover:cursor-pointer"
    >
      {text}
    </button>
  );
};

export default Button;

You now have a re-usable Button component which has some base styling but allows for configuration of what the button does by passing in a onClick() argument.

Header Component

Sticking with the theme of consistency, you want to create a <header/> component which you can use on all your organisation’s websites, ensuring a themed appearance on all applications.

Like before, create a Header.tsx file within src/components/, and paste in the following code:

// remote - .src/components/Header.tsx
import React from "react";

const Header: React.FC = () => {
  return (
    <header className="bg-gray-800 text-white p-4">
      <h1 className="text-2xl">Remote App Header</h1>
      <p className="text-white">Hi, Grant</p>
    </header>
  );
};

export default Header;

I’ve kept it simple, as this tutorial is for proof of concept purposes rather than aesthetic / real-world components.

How to Consume the Remote Components Within the Host

You have your remote components created, so next you need to get them into your host application and begin using them. This is quite simple now that you’ve already setup your vite.config.ts.

You could import the components into your App.tsx, but this is not best practice as it can bloat your App.tsx (entry point component). I’ve opted to create a RemoteWrapperComponent which pulls in the remote components and handles the business logic.

RemoteComponentWrapper:

Create a file called RemoteComponentWrapper.tsx in src/components, pasting the following code:

// host - ./src/components/RemoteComponentWrapper.tsx
import React, { Suspense } from "react";

const RemoteHeader = React.lazy(() => import("remote_app/Header"));
const RemoteButton = React.lazy(() => import("remote_app/Button"));

const LoadingSpinner = () => (
  <div className="flex justify-center p-4">
    <div className="animate-spin rounded-full h-8 w-8 border-b-2 border-gray-900"></div>
  </div>
);

export const RemoteComponentWrapper = () => {
  return (
    <div className="p-4">
      <Suspense fallback={<LoadingSpinner />}>
        <RemoteHeader />
      </Suspense>

      <div className="mt-4">
        <Suspense fallback={<LoadingSpinner />}>
          <RemoteButton
            text="Remote Button"
            onClick={() =>
              alert(
                "Well done you've imported the MF remote component successfully"
              )
            }
          />
        </Suspense>
      </div>
    </div>
  );
};

This component acts as a wrapper, handling some very simple business logic such as loading your remote components, handling a loading spinner whilst waiting for the remote, and passing your onClick event to the remote button.

Why Use React.lazy()?

The import with React.lazy isn’t required for Module Federation components – it’s more of a best practice for React apps when the remote module is:

• Loaded asynchronously at runtime, which Module Federation remotes almost always are

• You want React to handle the loading state and code-splitting gracefully – shown using the Suspense component

React.lazy + <Suspense> gives React a built-in way to pause rendering until the component is ready. Without it, you’d need manual loading state handling.

It also keeps your components looking “normal.” With React.Lazy, <RemoteHeader/> is just another component in your JSX.

Without it, you’d need something like:

const [Header, setHeader] = useState(null);

useEffect(() => {
  import("remote_app/Header").then(m => setHeader(() => m.default));
}, []);

return Header ? <Header /> : <LoadingSpinner />;

…which is messier and repeats for every remote component.

How to Handle TypeScript Errors

Inside your RemoteWrapperComponent you’re going to see the following error on your Button and Header imports.

Cannot find module 'remote_app/Button' or its corresponding type declarations.ts (2307)

You get this error because the remote modules are not defined with types, so both your remote and your host doesn’t know what this imported component is, nor does it know its structure (a key part to TypeScript development).

To fix this you will need to provide your host app with custom types.

Add a Type Declaration File

A type declaration file (if you’re unaware of them) has a .d.ts suffix.

Within your host app, create a file in src/types called remote-app.d.ts. Naming the file in this way lets us know the declarations within are related to the remote-app. This is useful especially when consuming multiple remotes.

Copy and paste the following declarations into your remote-app.d.ts file:

// host - ./src/types/remote.d.ts
declare module "remote_app/Button" {
  const Button: React.FC<{
    text: string;
    onClick?: () => void;
  }>;
  export default Button;
}

declare module "remote_app/Header" {
  const Header: React.FC;
  export default Header;
}

Now if you return to your RemoteWrapperComponent your errors should be gone. If they aren’t, restart your IDE (in VS Code you can open your command palette and select Restart Typescript Server).

How to Add RemoteWrapperComponent to App.tsx

Import the RemoteWrapperComponent into App.tsx.

I’ve removed all the boilerplate code and replaced with some basic styling to allow us to easily see what is the host, and what are the remote components.

Copy and paste the following code into your host App.tsx:

// host - ./src/App.tsx
import viteLogo from "/vite.svg";
import "./App.css";
import "./index.css";
import { RemoteComponentWrapper } from "./components/RemoteComponentWrapper";

function App() {
  return (
    <>
      <div className="px-6 border-2">
        <div className="flex justify-center items-center">
          <img src={viteLogo} alt="Example" />
        </div>
        <h1 className="text-2xl">Host Application</h1>
        <p>
          {" "}
          Welcome to the Host application, below are the components pulled from
          the remote application
        </p>
        <RemoteComponentWrapper />
      </div>
    </>
  );
}

export default App;

How to Serve the Remote App and Run Your Host

Due to how Vite works, you need to build the application before you preview / serve the application.

Make sure that your package.json file’s scripts block looks like this:

# remote-app
"scripts": {
    "dev": "vite",
    "build": "tsc -b && vite build",
    "lint": "eslint .",
    "preview": "vite preview --port 5001 --strictPort",
    "serve": "npm run build && npm run preview"
  },

# host-app
"scripts": {
    "dev": "vite",
    "build": "tsc -b && vite build",
    "lint": "eslint .",
    "preview": "vite preview --port 5000 --strictPort",
    "serve": "npm run build && npm run preview"
  },

In your terminal run:

cd ./remote-app

# run a build, and run / load the app on port 5000
npm run serve

You should see something like this:

Now you can run the host application by doing the same:

# change to the host-app in another terminal 
cd ../host-app

# build and run the application
npm run serve

If you open the localhost:5000 you should now see your host application with the remote components:

Next, if you click the button, you can see that it shows the message you configured from within the RemoteWrapperComponent:

The True Power of Micro Frontends

The true power of micro frontends lies in their ability to update the remote components, without the need to rebuild the host. To fully demonstrate this, keep the host running, and update the Button component on your remote-app.

Let’s update the remote components. Use the below code to update both the Button and Header components:

// remote - ./src/components/Header.tsx
import React from "react";

const Header: React.FC = () => {
  return (
    <header className="bg-gray-800 text-white p-4">
      <h1 className="text-2xl">Updated Remote App Header</h1>
      <p className="text-white">Hi, Grant</p>
    </header>
  );
};

export default Header;

// remote - ./src/components/Button.tsx
import React from "react";

interface ButtonProps {
  text: string;
  onClick?: () => void;
}

const Button: React.FC<ButtonProps> = ({ text, onClick }) => {
  return (
    <button
      onClick={onClick}
      className="px-4 py-2 bg-red-500 text-white rounded hover:bg-red-600 hover:cursor-pointer"
    >
      {text}
    </button>
  );
};

export default Button;

Once you’ve updated the remote components, run the following command in your remote-app folder:

npm run serve

Next, refresh your host app in the browser and you will see the updated app:

The update to the remote components is visible immediately, without restarting or rebuilding the host app. This highlights a key benefit of micro frontends: shared components are fetched from their own server via the remote.js file, enabling independent updates.

Final Thoughts

You've successfully built and deployed a micro frontend architecture – congrats! This basic implementation demonstrates the true power of Module Federation and the ability to update shared components without needing to rebuild and redeploy the entire host application.

This independence can dramatically accelerate development cycles and empower teams to work more autonomously.

I hope you’ve learned something from this article, and as always for more tutorials and discussions, connect with me on twitter/x.

By the end, you'll be equipped to evaluate whether microfrontends are the right solution for your team's specific needs.

I’ll cover the following:

• What are Microfrontends?

• Traditional Microfrontend Patterns

  • Server-Side Composition

  • iframes

  • Build Time Integration – Packages

• Modern Microfrontend Patterns

  • Module Federation

  • Single SPA

• Detailed Comparison

• Tradeoffs and Challenges with Module Federation

  • Setup Complexity

  • Runtime Challenges

  • Operational Concerns

• Conclusions

  • What’s next?

What are Microfrontends?

If you've heard about microservices on the backend, microfrontends represent a similar approach in the frontend world, with many of the same benefits.

Your team might adopt a microfrontend approach to enable team autonomy, reduce deployment risks, and scale development across multiple teams. Each team owns its technology stack, deployment cadence, and workflows. Yet they still deliver a single, cohesive user interface.

The overall idea is to move away from a big monolithic UI to decoupled UI codebases that can be owned, managed, and deployed by separate teams independently.

The simplest way to think about Microfrontends is the following:

Integrate one piece of UI into another

What can this piece of UI be, you may ask? Here are some examples:

• Pages – parts of a website owned by specific teams. For example, the Auth team may own login/signup pages, whereas the engagement team may own the marketing pages, and so on.

• Components – Components like header and footer are good candidates for a microfrontend approach as well. They’re relatively static but need to stay consistent across the website and may integrate with teams who own different sets of pages.

• Widgets – A recommendation widget may be owned by a recommendations team, for example, and it can be integrated into different parts of the page based on the context. This is different from a static component, as given the context, the recommendation widget may also fetch relevant data via APIs (also owned by the recommendations teams).

Traditional Microfrontend Patterns

After reading the definition of a microfrontend, you might be thinking, oh, wait, who builds UI with a big monolith these days anyway (except giants like Google)? If that’s the case, your team is most likely using one of these traditional approaches to building Microfrontends:

Server-Side Composition

This is the most common approach I've encountered across various organisations. The idea is to split your website based on route patterns or pages. For example, you might route users to the accounts team for any routes starting with /account/* (/account/login or /account/signup may fall under this pattern). Or you may have a similar route prefix for other parts of your web app, like /blog/* for the marketing section of your app.

This is typically implemented at the reverse proxy layer (such as using NGINX), which routes traffic to the appropriate downstream UI service based on the path matching.

iframes

Another common approach is using iframes, though this method has significant limitations.

Unlike server-side composition, which operates at the page level, iframes can integrate as widgets within pages. Using iframes, you can load another website as a part of the website you want to integrate it within using the <iframe> tag.

Some examples of this approach, which you may have seen, are websites that integrate Twitter feeds, Google Maps, and so on. Although these are examples of external widget integrations with iframes, companies may integrate certain widgets that are powered through iframes.

Build Time Integration – Packages

This approach involves publishing components as a UI library that other applications can integrate.

This is useful if you want to integrate full-blown apps with multiple pages, widgets, or static components like headers and footers, where this approach is pretty common.

Typically, this approach means that one team publishes their components as a package, while other teams integrate a specific version of this package.

In this example, it’s important to note that the Widget component is pulled in during the dependency install phase of the app. The web app can utilise this widget like its own component, which gets built together as one module and shipped to the users.

Modern Microfrontend Patterns

Module Federation

Module Federation enables you to integrate remote UI pieces within a host application at runtime. These pieces can be full pages, widgets, or components.

Module Federation originated as a Webpack 5 feature, extending the bundler's capabilities to load JavaScript code from remote sources at runtime.

Module Federation 2.0 is the evolution/improvement of the original Webpack 5 feature, with implementations available for other popular bundlers like RSPack and Vite as well.

Even if you’re using Webpack 5, I would recommend using Module Federation 2.0 as it takes care of some common gotchas that exist in the original Webpack 5 implementation.

Let’s take an example to understand some of the common pieces of Module Federation.

Imagine that we’ve a blog application, owned by the Content Team & a Widget, which is owned by the Recommendations team.

Now, let’s say the content team wants to integrate a recommendation widget within their application. Assume these teams have separate codebases hosted on different domains. The content team is on website.com & the recommendations team is on recommendation.com

Here’s how you can achieve this MFE integration via Module Federation:

Remote

Responsible for exposing JavaScript files as remote (for example, utilities, components, and so on).

In our example, it would be the Recommendation’s team acting as a remote & would require a configuration to ‘expose’ the Widget.

new ModuleFederationPlugin({
  name: 'recommendation',
  exposes: {
    './Widget': './src/Widget.js',
  }
})

Remote Entry

Remote entry is the URL for the entry point for a remote. A remote may expose multiple JavaScript files, & remoteEntry file would be aware of all of them.

Module Federation by default hosts the remote entry file at the root. In our example, recommendation teams might host their remote entry on https://recommendation.com/remoteEntry.js

Host

An independent website that consumes JavaScript from one or more remotes via Remote Entry. Think of remote entry as a namespace for your app under which it can export multiple things like components, utils, and so on, as exposed by a particular remote.

In our example, the Content Team would act as a Host & they’ll define the recommendation team’s remote entry within remotes configuration.

new ModuleFederationPlugin({
  name: 'content-blog',
  remotes: {
    "recommendation": 'recommendation@https://recommendation.com/remoteEntry.js',
  },
  // ... other configs
})

Shared

Both hosts and remote can specify dependencies as SemVer that are automatically negotiated and shared during runtime. These can include common framework dependencies, such as React, which may require being a singleton, or other vendor libraries that can be potentially shared.

Having the right shared configuration ensures that the client does not download libraries or code that is already available on the host when fetching UI pieces from a remote location, which is key for optimal performance when integrating Module Federation.

const deps = require("./package.json").dependencies;

new ModuleFederationPlugin({
  shared: {
    ...deps,
    react: {
      singleton: true,
      requiredVersion: deps.react,
    }
  },
  // ... other configs
})

Imports and Usage

Module Federation integration lets you use imports as if those JS files were available locally. Module Federation does all the stitching behind the scenes at runtime, in terms of fetching the remote entry and appropriate dependencies to make it available when you use it.

// Import is of the format - <remote>/<expose-from-remote>
import Widget from 'recommendation/Widget';

// Render somewhere, making sure to handle loading via Suspense
// & errors via error boundary in React
<ErrorBoundary>
  <Suspense fallback={<Loading />}
    <Widget />
  </Suspense>
</ErrorBoundary>

In a nutshell, the module federation concept is this simple —

Fetching JS code (components, utils, and so on) from a remote server at runtime and still being able to share dependencies and be performant while doing so.

Single SPA

When you look up microfrontends, Single SPA often appears as a popular solution. But its primary use case is quite specific: integrating components across multiple frameworks (for example, React + Angular + Vue in the same application). Here's how it works in practice:

Single SPA acts as a JavaScript router that mounts and unmounts entire applications based on URL routes. Each "single-spa application" is a framework-specific app that gets loaded when its route becomes active.

// Register applications with Single SPA
registerApplication({
 name: '@mycompany/react-app',
 app: () => System.import('@mycompany/react-app'),
 activeWhen: ['/react-app']
});

registerApplication({
 name: '@mycompany/angular-app', 
 app: () => System.import('@mycompany/angular-app'),
 activeWhen: ['/angular-app']
});

Single SPA handles the "orchestration" part – deciding which app should be active and managing their lifecycles. It doesn't solve the "how do I load remote code" problem – you still need to pair it with one of the approaches we've discussed (Module Federation, build-time packages, and so on).

If your applications use the same framework (like all React), you can skip Single SPA entirely and use Module Federation directly. Single SPA adds complexity that's only justified when you truly need multi-framework integration.

Detailed Comparison

Tradeoffs and Challenges with Module Federation

The primary tradeoff in using Module Federation is the initial setup effort, which I briefly discussed in the previous comparison table.

Here are some other challenges to anticipate when integrating via Module Federation:

Setup Complexity

1. Bundler-specific challenges – Some things may require you to know your bundler's internals to make the integration work for your app. For example, with Webpack 5, if your remote not only exposes federated components but also serves a user experience, you’ll need the appropriate chunk setup to make that work. This is because Module Federation by default expects a certain chunk optimisation strategy and exposes the remoteEntry from the root of the app.

2. Shared dependencies – You'll need to review your dependencies to make sure you share as many dependencies as possible to optimise bundle size and loading performance. You’ll also need to mark critical libraries (like React) as singletons to prevent runtime conflicts.

Runtime Challenges

1. Cross domain – if your remote is on a different subdomain, for example remote.website.com and is being loaded from host.website.com You’ll need appropriate handling for CORS on your server to allow data fetching from the host’s subdomain. You’ll also need an appropriate credentials fetch configuration to make sure the browser sends the authentication cookies in data fetching requests to your remote endpoints.

2. Styling conflicts – You’ll want to make sure the remote’s styles don’t override the host’s styles and that the remote components don’t inherit unintended styles from the host. There are multiple strategies here, from using styled components to a virtual DOM.

Operational Concerns

1. Observability and Analytics – Based on your requirements, you may want to either share an instance of your observability scripts, for example, an error monitoring service, or instantiate a completely different one within your MFE’s context. This becomes challenging, as there is no ‘index’ file being rendered, but rather components that are being exposed from the remotes.

2. Deployment & Caching – It’s recommended that MFE remote bundles be hosted on S3 buckets for high reliability as opposed to loading them from a remote server. You may require appropriate long-term caching for files other than the remoteEntry.js which is typically non-hashed and contains the link to other dependencies to be loaded.

Conclusion

Microfrontends offer a compelling solution for scaling frontend development across multiple teams, with Module Federation emerging as the most flexible modern approach.

While traditional methods like server-side composition remain valuable for specific use cases, Module Federation provides the runtime flexibility and performance characteristics needed for complex applications.

The decision ultimately depends on your team’s structure, technical requirements, and tolerance for implementation complexity. Start with simpler approaches if you're new to microfrontends, then consider Module Federation as your needs evolve.

What’s next?

This article was more about giving you a bird’s-eye view of the landscape. I’ll be writing more on Module Federation and going beyond the basics next. I’ll cover the technical challenges in more detail, along with possible solutions. Watch out for the same!