Glen Thomas

Software / Platform Engineer

7 minute read Software Engineering

Modern front-end apps are increasingly complex, often built by multiple teams with different goals, timelines, and domains. While microservices helped decouple the backend, front-end monoliths still cause bottlenecks in scaling, deployment, and developer ownership.

Enter micro-frontends—the architectural pattern that brings modularity, autonomy, and scalability to the UI layer. But are they the silver bullet? And what trade-offs come with them?

This post explores what micro-frontends are, when they make sense, and how to implement them without creating chaos.

What Are Micro-Frontends (and Why Do They Exist)?

Micro-frontends apply the principles of microservices to front-end development—breaking down a monolithic UI into independently deliverable, loosely coupled pieces.

Just like backend services handle different domains (auth, orders, payments), micro-frontends allow different teams to own and deploy parts of the UI (dashboard, checkout, profile) independently.

Common Drivers

Large Teams Working on the Same App

When multiple teams collaborate on a single front-end codebase, coordination becomes a major challenge. Teams may step on each other’s toes, causing merge conflicts, inconsistent coding standards, and delays in feature delivery. Shared deployments mean that a bug or delay in one part of the app can block releases for everyone, slowing down the entire organization.

Micro-frontends address this by allowing each team to own, build, and deploy their part of the UI independently. This autonomy reduces bottlenecks, minimises cross-team dependencies, and enables faster, safer releases. Teams can innovate and iterate at their own pace, improving overall productivity and code quality.

Desire for Independent Deployments

In large front-end projects, teams want to deploy their part of the application without waiting for or affecting other teams. This allows:

  • Faster release cycles (each team can ship features or fixes independently)
  • Reduced risk (a bug in one micro-frontend doesn’t break the whole app)
  • Team autonomy (teams own their code and deployment process)

Micro-frontends solve this by splitting the UI into separate, independently developed and deployed pieces. Each micro-frontend is:

  • Built and deployed as its own bundle (often as a separate npm package or static asset)
  • Loaded into the main app at runtime (using techniques like module federation, iframes, or dynamic imports)
  • Versioned and released independently

This way, teams can update, rollback, or scale their micro-frontend without coordinating with the entire organisation.

Long Build and Test Times in Monoliths

As front-end applications grow, monolithic codebases can lead to slow build and test cycles. Every change, no matter how small, may require rebuilding and retesting the entire application. This increases feedback loops, delays deployments, and frustrates developers.

Micro-frontends help by isolating codebases, so teams only build and test their own slice of the UI. This speeds up CI/CD pipelines and makes it easier to maintain high code quality as the app scales.

Micro-Frontend Architecture Models

Curious how micro-frontends actually come together in real-world apps? Let’s break down the main ways teams stitch these pieces into a cohesive UI. There’s no one-size-fits-all approach. Each model has its own strengths, trade-offs, and ideal scenarios. Here’s what you need to know about build-time, run-time, and server-side integration, and how to pick the right fit for your team.

Build-Time Integration

Teams build separate apps, then combine them at build time (e.g. using Webpack Module Federation).

  • Pros: Easier CI/CD, more control
  • Cons: Tight coupling, slower to adopt independently

Run-Time Integration

Apps are composed at runtime (e.g. loading remote apps via iframe, custom loaders, or dynamic imports).

  • Pros: Independent deployments, decoupled teams
  • Cons: More complex to test, manage shared state, and route

Example Webpack Module Federation App With Run-Time Integration

Architecture:

  • app-shell: The container application (host)
  • remote-app: A micro-frontend exposed to the host

Project structure:

micro-frontend-demo/
├── app-shell/
│   ├── src/
│   │   ├── App.tsx
│   │   ├── index.tsx
│   ├── tsconfig.json
│   └── webpack.config.js
└── remote-app/
    ├── src/
    │   ├── Widget.tsx
    │   ├── index.ts
    ├── tsconfig.json
    └── webpack.config.js

remote-app/webpack.config.js

const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  entry: './src/index.ts',
  mode: 'development',
  devServer: {
    port: 3001,
  },
  output: {
    publicPath: 'auto',
    clean: true,
  },
  resolve: {
    extensions: ['.ts', '.tsx', '.js'],
  },
  module: {
    rules: [
      { test: /\.tsx?$/, loader: 'ts-loader', exclude: /node_modules/ },
    ],
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'remoteApp',
      filename: 'remoteEntry.js',
      exposes: {
        './Widget': './src/Widget',
      },
      shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
    }),
    new HtmlWebpackPlugin({
      template: 'public/index.html',
    }),
  ],
};

remote-app/tsconfig.json

{
  "compilerOptions": {
    "target": "ES6",
    "module": "ESNext",
    "jsx": "react-jsx",
    "strict": true,
    "esModuleInterop": true,
    "moduleResolution": "Node"
  }
}

remote-app/src/Widget.tsx

import React from 'react';

const Widget: React.FC = () => {
  return <div style=>📦 Remote Widget (TypeScript)</div>;
};

export default Widget;

app-shell/webpack.config.ts

const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  entry: './src/index.tsx',
  mode: 'development',
  devServer: {
    port: 3000,
  },
  output: {
    publicPath: 'auto',
    clean: true,
  },
  resolve: {
    extensions: ['.ts', '.tsx', '.js'],
  },
  module: {
    rules: [
      { test: /\.tsx?$/, loader: 'ts-loader', exclude: /node_modules/ },
    ],
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'appShell',
      remotes: {
        remoteApp: 'remoteApp@http://localhost:3001/remoteEntry.js',
      },
      shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
    }),
    new HtmlWebpackPlugin({
      template: 'public/index.html',
    }),
  ],
};

app-shell/tsconfig.json

{
  "compilerOptions": {
    "target": "ES6",
    "module": "ESNext",
    "jsx": "react-jsx",
    "strict": true,
    "esModuleInterop": true,
    "moduleResolution": "Node"
  }
}

app-shell/src/App.tsx

import React, { Suspense } from 'react';

// Dynamically import the remote widget
const RemoteWidget = React.lazy(() => import('remoteApp/Widget'));

const App: React.FC = () => {
  return (
    <div style=>
      <h1>🧩 App Shell (TypeScript)</h1>
      <Suspense fallback={<div>Loading Remote Widget...</div>}>
        <RemoteWidget />
      </Suspense>
    </div>
  );
};

export default App;

app-shell/src/index.tsx

import React from 'react';
import ReactDOM from 'react-dom/client';
import App from './App';

const root = ReactDOM.createRoot(document.getElementById('root')!);
root.render(<App />);

Run it locally:

  1. Start remote-app on port 3001
  2. Start app-shell on port 3000
  3. Navigate to http://localhost:3000 — the shell will load the Widget from the remote app at runtime

Server-Side Composition

  • The server assembles the UI from different apps, often using edge rendering or server-side includes.
  • Use Cases: Public-facing websites, CMS-heavy experiences

When Should You (Actually) Use Micro-Frontends?

  • ✅ You have multiple teams working on different parts of a large, complex UI
  • ✅ You need independent deployments to reduce coordination overhead
  • ✅ You have a monolith slowing down your delivery cadence
  • ✅ Your app spans multiple domains or customer-facing portals
  • ❌ You’re a small or medium-sized team
  • ❌ You just want to use different frameworks for fun
  • ❌ You don’t have strong DevOps or CI/CD maturity

Key Challenges to Address

Performance

Multiple bundles → more HTTP requests

Solutions: Shared runtime, HTTP/2, critical path rendering, performance budgets

Shared State and Routing

How do you share user session or global app state?

Strategies: Use global event buses, shared libraries, or local state with synchronisation patterns

Consistent UI/UX

Risk: Different teams build inconsistent designs Solution: Shared design system or component library (Storybook, Figma guidelines, etc.)

Dev Experience and Tooling

A smooth developer experience is crucial for micro-frontends to succeed. Without the right tooling, teams can quickly become bogged down by friction and complexity.

You’ll want tools that help you:

  • Scaffold new frontends: Quickly spin up new micro-apps with consistent templates, shared configs, and best practices baked in.
  • Manage local development across boundaries: Run multiple micro-frontends together locally, with hot reloading and seamless integration, so teams can develop and test in a realistic environment.
  • Deploy independently: Set up CI/CD pipelines that let each micro-frontend ship on its own schedule, without waiting for a monolithic release train.

Look for solutions that automate repetitive tasks, enforce standards, and make it easy for new team members to get started. Tools like Nx, Bit, or custom CLI scripts can help streamline the process. The goal: empower teams to move fast without stepping on each other’s toes.

Real-World Implementation Tips

  • Use Webpack Module Federation for runtime composition with shared libraries (React, etc.)
  • Establish Contracts: APIs between micro-frontends should be clearly defined, versioned, and documented
  • Invest in Observability: Logging and error tracking should cover each micro-app with context
  • Set Organisational Guardrails: Enforce naming conventions, testing standards, and release policies

Alternatives and Middle Grounds

  • Modular Monoliths: A single app with clearly defined boundaries, perhaps enforced by folder structure or build tools
  • Vertical Slice Ownership: One team owns full-stack features but within a monolith
  • Component Federation Only: Share common components across apps, but not full micro-frontends

Conclusion

Micro-frontends are not a silver bullet, but they can be a powerful solution for organisations with scaling problems at the UI layer. They give teams autonomy and velocity, but require coordination, standards, and operational maturity.

Start small. Pick one slice of your app to isolate and experiment. Measure the trade-offs and scale intentionally.

Leave a comment

You may also enjoy