5 Micro Frontend Integration Patterns You Should Know

There is no single way to integrate Micro Frontends. The approach you choose directly impacts performance, developer experience, shared state capabilities, and deployment independence. Choosing the wrong pattern early can force a costly rewrite later.

In this article, you will learn the five main Micro Frontend integration patterns, see real code examples for each one, understand the trade-offs, and learn why Module Federation with shared npm packages is the most widely adopted approach for production applications.

New to Micro Frontend? Start with What is Micro Frontend Architecture? first. Already decided on MFE? Read Micro Frontend vs Monolith for the decision framework.

Overview: 5 Integration Patterns

Most production MFE applications use Pattern 1 + Pattern 5 together — shared npm workspace packages for common code (store, API, SEO) and Module Federation for runtime integration of independent MFE applications.

Pattern 1: Build-Time Integration (npm Workspace Packages)

Shared code — Redux store, API client, SEO utilities — is packaged as npm workspace packages that all MFEs import at build time. This is not technically "runtime integration" but it is a critical piece of every MFE architecture.

How It Works

1. Create shared packages in a packages/ directory
2. Configure npm workspaces (opens in a new tab) or Turborepo (opens in a new tab) in the root package.json
3. Every MFE imports from the shared package name (e.g., @myapp/store)
4. When you run npm install, workspaces symlink the packages automatically

Code Example

// Root package.json — npm workspaces configuration
{
  "name": "my-ecommerce-app",
  "workspaces": [
    "apps/*",
    "packages/*",
    "packages/*/*"
  ],
  "scripts": {
    "dev": "turbo run dev --concurrency=15",
    "build": "turbo run build",
    "start": "turbo run start"
  }
}

What Gets Shared as Build-Time Packages

When to Use

Pattern 2: Server-Side Integration (SSR / ISR)

In a Next.js MFE architecture, the server can pre-render pages before sending HTML to the browser. This includes Static Site Generation (SSG), Server-Side Rendering (SSR), and Incremental Static Regeneration (ISR) — where pages are statically generated but automatically refreshed at intervals.

How It Works

1. Next.js MFE uses getStaticProps with revalidate for ISR
2. Page is generated as static HTML at build time
3. After the revalidate interval (e.g., 300 seconds), Next.js regenerates the page in the background
4. Users always get fast static HTML — no loading spinner
5. A CMS can trigger on-demand revalidation via an API route

Code Example

// apps/host/pages/shop/[category].tsx
// Next.js Incremental Static Regeneration (ISR)
export async function getStaticProps({ params }) {
  const products = await fetchProductsByCategory(params.category)

  return {
    props: { products },
    revalidate: 300, // Re-generate page every 5 minutes
  }
}

// Result: Page is statically generated at build time
// After 5 minutes, Next.js regenerates the page in the background
// Users always get fast static HTML — no loading spinner

When to Use

Pattern 3: Runtime Integration via iframes

Each MFE is loaded inside an <iframe> element. The MFEs are completely isolated — separate DOM, separate JavaScript context, separate CSS.

Code Example

<!-- Pattern 3: iframe integration (NOT recommended) -->
<iframe
  src="https://products.example.com/catalog"
  width="100%"
  height="600"
  style="border: none;"
  title="Product Catalog"
/>

<!-- Problems:
  - No shared state (Redux store is separate)
  - No shared auth (login required separately in each iframe)
  - Poor performance (each iframe loads full React bundle)
  - No CSS consistency (styles don't leak across iframes)
  - Accessibility issues (screen readers struggle with iframes)
  - SEO invisible (Google cannot crawl iframe content)
-->

Why This Pattern Is NOT Recommended

Pattern 4: Runtime Integration via JavaScript

MFE components are loaded at runtime using React.lazy() (React apps) or next/dynamic (Next.js apps). The remote bundle is fetched over the network when needed, and the component renders like a normal React component.

This pattern relies on Module Federation to make remote imports work (see Pattern 5), but the loading mechanism itself is standard React.

Code Example — React Host (React.lazy)

// Pattern 4: Runtime JavaScript — React.lazy() with error handling
// apps/host/src/App.jsx (React Host application)
import React, { Suspense, lazy } from 'react'

// Each Remote MFE is loaded at runtime via Module Federation
// .catch() provides a fallback if the remote fails to load
const ProductsMFE = lazy(() =>
  import('ProductManagement/ProductsMFE').catch((err) => {
    console.error('Failed to load ProductsMFE', err)
    return { default: () => <div>Failed to load Products Module</div> }
  })
)

const OrdersMFE = lazy(() =>
  import('OrdersManagement/OrdersMFE').catch((err) => {
    console.error('Failed to load OrdersMFE', err)
    return { default: () => <div>Failed to load Orders Module</div> }
  })
)

const AnalyticsMFE = lazy(() =>
  import('AnalyticsManagement/AnalyticsMFE').catch((err) => {
    console.error('Failed to load AnalyticsMFE', err)
    return { default: () => <div>Failed to load Analytics Module</div> }
  })
)

const LoadingFallback = () => (
  <div className="flex items-center justify-center h-screen">
    <div className="animate-spin rounded-full h-12 w-12 border-b-2 border-blue-600 mx-auto" />
    <p className="mt-4 text-gray-600">Loading...</p>
  </div>
)

// Usage in routes:
<Suspense fallback={<LoadingFallback />}>
  <ProductsMFE />
</Suspense>

Code Example — Next.js Host (next/dynamic)

// Pattern 4 in Next.js: next/dynamic with ssr: false
// apps/host/pages/login/index.tsx (Next.js Host application)
import dynamic from 'next/dynamic'
import { Suspense } from 'react'
import { useRouter } from 'next/navigation'

const RemoteLogin = dynamic(
  () => import('Auth/Login'),
  {
    loading: () => <LoadingState />,
    ssr: false,
  }
)

export default function LoginPage() {
  const router = useRouter()

  const handleNavigate = (path, state) => {
    if (state?.mobileNumber) {
      sessionStorage.setItem('mobileNumber', state.mobileNumber)
    }
    router.push(path)
  }

  return (
    <Suspense fallback={<LoadingState />}>
      <RemoteLogin onNavigate={handleNavigate} />
    </Suspense>
  )
}

React.lazy vs next/dynamic

Pattern 5: Module Federation (Webpack 5) — The Recommended Approach

Webpack Module Federation (opens in a new tab) is a Webpack 5 plugin that allows separate builds to share modules at runtime. Each MFE exposes components via a remoteEntry.js file. The Host declares remotes and loads them dynamically. Shared dependencies (React, Redux) are loaded as singletons — one instance for all MFEs.

For Next.js applications, use NextFederationPlugin (opens in a new tab) which extends Module Federation for SSR, page routing, and Next.js-specific asset loading.

How It Works

1. Each Remote MFE exposes components via remoteEntry.js
2. The Host declares remotes — URLs pointing to each MFE's remoteEntry.js
3. At runtime, the Host fetches the remote bundle and renders the component
4. Shared dependencies (React, Redux, store packages) are loaded once as singletons

Code Example — Mixed Architecture (Next.js Host + React & Next.js Remotes)

Next.js Host (NextFederationPlugin)

// apps/host/next.config.js — LOCAL DEVELOPMENT
const { NextFederationPlugin } = require('@module-federation/nextjs-mf')

module.exports = {
  reactStrictMode: false,
  transpilePackages: ['@myapp/seo', '@myapp/store', '@myapp/api'],

  webpack(config, { isServer }) {
    config.plugins.push(
      new NextFederationPlugin({
        name: 'Host',
        filename: 'static/chunks/remoteEntry.js',
        remotes: {
          // Each MFE runs on its own localhost port
          Auth:     'Auth@https://localhost:3001/remoteEntry.js',
          Account:  'Account@https://localhost:3002/remoteEntry.js',
          Cart:     'Cart@https://localhost:3003/remoteEntry.js',
          Content:  'Content@http://localhost:3004/content/_next/static/'
            + (isServer ? 'ssr' : 'chunks') + '/remoteEntry.js',
          Products: 'Products@http://localhost:3005/products/_next/static/'
            + (isServer ? 'ssr' : 'chunks') + '/remoteEntry.js',
          Support:  'Support@https://localhost:3006/remoteEntry.js',
        },
        shared: {
          react:              { singleton: true, requiredVersion: false, eager: false },
          'react-dom':        { singleton: true, requiredVersion: false, eager: false },
          'react-redux':      { singleton: true, requiredVersion: false, eager: false },
          '@reduxjs/toolkit':  { singleton: true, requiredVersion: false, eager: false },
          '@myapp/store':     { singleton: true, strictVersion: true, requiredVersion: '1.0.0' },
          '@myapp/api':       { singleton: true, strictVersion: true, requiredVersion: '1.0.0' },
          '@myapp/seo':       { singleton: true, strictVersion: true, requiredVersion: '1.0.0' },
        },
        extraOptions: {
          exposePages: true,
          enableImageLoaderFix: true,
          enableUrlLoaderFix: true,
          automaticAsyncBoundary: true,
        },
      })
    )
    return config
  },
}

React Remote (ModuleFederationPlugin)

// apps/auth/webpack.config.js — LOCAL DEVELOPMENT
const { ModuleFederationPlugin } = require('webpack').container
const dependencies = require('./package.json').dependencies

module.exports = {
  mode: 'development',
  output: {
    publicPath: 'https://localhost:3001/',
    filename: '[name].bundle.js',
  },
  devServer: {
    port: 3001,
    historyApiFallback: true,
    headers: { 'Access-Control-Allow-Origin': '*' },
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'Auth',
      filename: 'remoteEntry.js',
      exposes: {
        './Login':     './src/components/Login.jsx',
        './OTPVerify': './src/components/OTPVerify.jsx',
        './Register':  './src/components/Register.jsx',
      },
      shared: {
        react:              { singleton: true, requiredVersion: dependencies.react, eager: false },
        'react-dom':        { singleton: true, requiredVersion: dependencies['react-dom'], eager: false },
        'react-redux':      { singleton: true, requiredVersion: dependencies['react-redux'], eager: false },
        '@reduxjs/toolkit':  { singleton: true, requiredVersion: dependencies['@reduxjs/toolkit'], eager: false },
        '@myapp/store':     { singleton: true, strictVersion: true, requiredVersion: '1.0.0' },
        '@myapp/api':       { singleton: true, strictVersion: true, requiredVersion: '1.0.0' },
      },
    }),
  ],
  optimization: { splitChunks: false },
}

Next.js Remote (NextFederationPlugin)

// apps/products/next.config.js — Next.js Remote with NextFederationPlugin
const NextFederationPlugin = require('@module-federation/nextjs-mf')

module.exports = {
  reactStrictMode: true,
  output: 'standalone',
  basePath: '/products',
  assetPrefix: '/products',
  transpilePackages: ['@myapp/seo', '@myapp/store', '@myapp/api'],

  webpack: (config, options) => {
    config.plugins.push(
      new NextFederationPlugin({
        name: 'Products',
        filename: 'static/chunks/remoteEntry.js',
        exposes: {
          './ProductList':       './components/ProductList.tsx',
          './ProductDetailPage': './pages/products/index.tsx',
        },
        shared: {
          react:              { singleton: true, requiredVersion: false, eager: false },
          'react-dom':        { singleton: true, requiredVersion: false, eager: false },
          'react-redux':      { singleton: true, requiredVersion: false, eager: false },
          '@reduxjs/toolkit':  { singleton: true, requiredVersion: false, eager: false },
          '@myapp/store':     { singleton: true, strictVersion: true, requiredVersion: '1.0.0' },
          '@myapp/api':       { singleton: true, strictVersion: true, requiredVersion: '1.0.0' },
          '@myapp/seo':       { singleton: true, strictVersion: true, requiredVersion: '1.0.0' },
        },
        extraOptions: {
          automaticAsyncBoundary: true,
        },
      })
    )
    return config
  },
}

React Host (ModuleFederationPlugin)

// apps/host/webpack.config.js — LOCAL DEVELOPMENT
const { ModuleFederationPlugin } = require('webpack').container
const dependencies = require('./package.json').dependencies

module.exports = {
  mode: 'development',
  output: {
    publicPath: '/',
    filename: '[name].bundle.js',
  },
  devServer: {
    port: 4000,
    historyApiFallback: true,
    headers: {
      'Access-Control-Allow-Origin': '*',
      'Access-Control-Allow-Methods': 'GET, POST, PUT, DELETE, PATCH, OPTIONS',
      'Access-Control-Allow-Headers': 'X-Requested-With, content-type, Authorization',
    },
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'Host',
      filename: 'remoteEntry.js',
      remotes: {
        // Each MFE on its own localhost port
        ProductManagement:   'ProductManagement@https://localhost:4002/remoteEntry.js',
        InventoryManagement: 'InventoryManagement@https://localhost:4003/remoteEntry.js',
        OrdersManagement:    'OrdersManagement@https://localhost:4004/remoteEntry.js',
        PricingManagement:   'PricingManagement@https://localhost:4005/remoteEntry.js',
        AnalyticsManagement: 'AnalyticsManagement@https://localhost:4007/remoteEntry.js',
        SettingsManagement:  'SettingsManagement@https://localhost:4009/remoteEntry.js',
      },
      shared: {
        react:              { singleton: true, requiredVersion: dependencies.react },
        'react-dom':        { singleton: true, requiredVersion: dependencies['react-dom'] },
        'react-router-dom': { singleton: true, requiredVersion: dependencies['react-router-dom'] },
        '@reduxjs/toolkit':  { singleton: true, requiredVersion: '^2.6.0' },
        'react-redux':      { singleton: true, requiredVersion: '^9.2.0' },
        '@myapp/store':     { singleton: true, requiredVersion: '0.0.1' },
      },
    }),
  ],
}

Key Differences: Local vs Production

NextFederationPlugin vs ModuleFederationPlugin

Key Configuration Rules

1. singleton: true on all shared dependencies — prevents duplicate React instances
2. strictVersion: true on shared workspace packages — catches version mismatches immediately
3. eager: false on shared deps — loaded on demand, not upfront
4. basePath + assetPrefix on Next.js remotes — required for sub-path routing (e.g., /products/)
5. isServer ? 'ssr' : 'chunks' in remote URLs — Next.js needs different remoteEntry for SSR vs client

Which Pattern Should You Choose?

The Recommended Stack

Build-Time packages (Pattern 1) for shared utilities + Module Federation (Pattern 5) for runtime integration + Runtime JavaScript (Pattern 4) for lazy loading = the most battle-tested MFE architecture for production applications.

For official documentation, see the Webpack Module Federation docs (opens in a new tab), NextFederationPlugin on npm (opens in a new tab), and Turborepo docs (opens in a new tab).

Summary

What's Next?

Now that you understand the five integration patterns, the next step is learning how MFEs communicate with each other — shared state, callback props, URL routing, and shared API layers.

← Back to Micro Frontend vs Monolith

Continue to Micro Frontend Communication Patterns →

Frequently Asked Questions

What are the different Micro Frontend integration patterns?

There are 5 main integration patterns: Build-Time Integration (npm packages shared via workspaces), Server-Side Integration (SSR/ISR with Next.js), Runtime via iframes (isolated but limited), Runtime via JavaScript (React.lazy or next/dynamic loading remote bundles), and Module Federation (Webpack 5 plugin that loads remote components at runtime with shared dependencies).

Why is Module Federation the best approach for Micro Frontends?

Module Federation allows MFEs to share dependencies like React and Redux as singletons at runtime — avoiding duplicate bundles. Each MFE deploys independently with its own remoteEntry.js file. The Host loads remote components on demand without rebuilding. Combined with shared npm workspace packages for state and API layers, it provides the best balance of independence and shared functionality.

What is the difference between NextFederationPlugin and ModuleFederationPlugin?

ModuleFederationPlugin is Webpack 5's built-in plugin for standard React apps. NextFederationPlugin from @module-federation/nextjs-mf extends it for Next.js — handling SSR chunks, page routing, static asset loading, and the distinction between server-side (ssr/) and client-side (chunks/) remoteEntry.js files. Use NextFederationPlugin when your Host or Remote is a Next.js application.

Why should you avoid iframes for Micro Frontend integration?

Iframes create completely isolated contexts — no shared Redux state, no shared authentication, no shared CSS. Each iframe loads a full React bundle independently, causing poor performance. Screen readers struggle with iframe content, and Google cannot crawl iframe-loaded content for SEO. Module Federation solves all of these problems while still keeping MFEs independently deployable.

Can you mix React and Next.js Micro Frontends in the same application?

Yes. A Next.js Host can load both Next.js remotes (using NextFederationPlugin with basePath and assetPrefix) and plain React remotes (using standard ModuleFederationPlugin). Next.js remotes have a different remoteEntry.js path pattern (_next/static/chunks/ for client, _next/static/ssr/ for server) while React remotes serve remoteEntry.js directly from their publicPath.