Micro Frontends Architecture: A Practical Implementation Guide

Micro frontends solve scaling challenges in large teams by enabling independent development and deployment. 1) Choose an integration strategy: use Module Federation in Webpack 5 for runtime loading and true independence, build-time integration for simple setups, or iframes/web components for strong isolation. 2) Define team boundaries by business domains, with each team owning a micro frontend’s stack, CI/CD, and deployment. 3) Address cross-cutting concerns: share dependencies via Module Federation’s singleton setting, enforce a shared design system, centralize top-level routing in the host app, and communicate via custom events or URLs instead of global state. 4) Implement independent DevOps: each team manages their repo, pipeline, and monitoring, while the host monitors remote health and provides fallbacks for failures. 5) Adopt incrementally by extracting a well-contained page into a standalone micro frontend and integrating it via Module Federation, then repeat. This approach balances autonomy with consistency, making scalable frontend development practical for large organizations.

Micro Frontends are not just a buzzword—they’re a practical solution to scaling frontend development in large teams. The idea is simple: break a monolithic frontend into smaller, independently deployable pieces, each owned by a distinct team. But how do you actually implement this without creating chaos? Let’s walk through a real-world approach.

What Problem Are We Solving?

Before jumping into code, understand the pain points:

• Slow builds and deployments across large apps.
• Team bottlenecks when multiple teams work on the same codebase.
• Tech stack lock-in, where upgrading or experimenting is risky.
• Release coupling, where one team’s bug delays everyone.

Micro frontends help by enabling team autonomy, independent deployments, and technology diversity.

Step 1: Choose Your Integration Strategy

There’s no one-size-fits-all. Here are the most practical options:

Option A: Build-Time Integration (Simple but Limited)

Each micro frontend is built separately and then combined into a shell app at deploy time.

• ✅ Easy to set up with existing tooling.
• ❌ Teams still share a deployment pipeline.
• ❌ No true independence.

Best for: small-scale apps or teams transitioning from monoliths.

Option B: Runtime Integration via Module Federation (Webpack 5)

This is the game-changer. Webpack 5’s Module Federation lets you load JavaScript from one app into another at runtime.

// In the host (container) app
new ModuleFederationPlugin({
  name: "container",
  remotes: {
    dashboard: "dashboard@https://dashboard-app.com/remoteEntry.js",
    profile: "profile@https://profile-app.com/remoteEntry.js",
  },
  shared: ["react", "react-dom"],
});

// In the remote (micro frontend) app
new ModuleFederationPlugin({
  name: "dashboard",
  filename: "remoteEntry.js",
  exposes: {
    "./Dashboard": "./src/components/Dashboard",
  },
  shared: ["react", "react-dom"],
});

Now, the host can dynamically load components:

import { lazy, Suspense } from "react";

const Dashboard = lazy(() => import("dashboard/Dashboard"));

function App() {
  return (
    <Suspense fallback="Loading...">
      <Dashboard />
    </Suspense>
  );
}

✅ True independence
✅ Different tech stacks (as long as they expose modules)
✅ Independent deployments

Use this if you're using Webpack 5 and want flexibility.

Option C: Iframe or Web Components (Isolation-First)

When you need strong isolation (e.g., security, legacy systems):

• Iframes: Full sandboxing but poor UX (scrolling, styling, communication).
• Web Components: Native browser support, framework-agnostic, but need polyfills and custom event handling.

Best for: high-security environments or integrating non-JS apps.

Step 2: Define Clear Team Boundaries

Ownership matters. Each micro frontend should map to a business domain, not a UI component.

Examples:

• orders@https://orders.company.com
• user-profile@https://profile.company.com
• analytics@https://analytics.company.com

Each team:

• Chooses their stack (React, Vue, Angular, etc.)
• Owns their CI/CD pipeline
• Publishes their remoteEntry.js endpoint

Avoid overlap. No two teams should own parts of the same page unless clearly decoupled.

Step 3: Solve Cross-Cutting Concerns

Even when apps are split, users expect a seamless experience.

1. Shared Dependencies

Use shared in Module Federation to avoid duplicate React, Lodash, etc.

shared: {
  react: { singleton: true, eager: true },
  "react-dom": { singleton: true, eager: true },
}

singleton: true ensures only one version loads—critical for React context and hooks.

2. Global Styles and Design System

Don’t let each team redefine buttons.

• Host app provides base CSS (fonts, resets, tokens).
• Publish a shared design system package (e.g., @company/ui) via npm or CDN.
• Enforce usage via linting or PR reviews.

3. Routing

The host app should control routing.

// Container App
<Route path="/dashboard" element={<Dashboard />} />
<Route path="/profile" element={<Profile />} />

Each micro frontend handles its internal routes (e.g., /profile/settings), but the shell manages top-level navigation.

4. State and Communication

Avoid shared global state. Instead:

• Use URLs and query params to pass data.
• Use custom events for lightweight communication:

// From micro frontend
window.dispatchEvent(new CustomEvent("user-login", { detail: user }));

// In host or another app
window.addEventListener("user-login", (e) => console.log(e.detail));

For complex cases, consider a lightweight message bus or context passed via props.

Step 4: DevOps & Observability

Independent apps mean independent pipelines.

✅ Each team has:

• Their own repo
• CI/CD (GitHub Actions, Jenkins, etc.)
• Staging environment
• Monitoring (Sentry, LogRocket, etc.)

✅ Host app monitors:

• Health of remote entries
• Fallback UIs if a micro frontend fails to load

Example error boundary:

class RemoteFallback extends React.Component {
  state = { hasError: false };

  static getDerivedStateFromError() {
    return { hasError: true };
  }

  render() {
    if (this.state.hasError) {
      return <div>Dashboard is temporarily unavailable.</div>;
    }
    return this.props.children;
  }
}

Step 5: Incremental Adoption

You don’t need to rewrite everything.

Start by:

1. Identifying a well-contained page (e.g., “Settings” or “Reports”).
2. Extracting it into a standalone app with Module Federation.
3. Loading it into the main app as a remote.
4. Repeat.

This way, you prove value early and reduce risk.

Final Thoughts

Micro frontends aren’t free. You trade simplicity for scalability.

They make sense when:

• You have multiple teams
• You deploy often
• You want to experiment with tech stacks
• Your frontend has become a bottleneck

But if you’re a small team, a well-structured monolith might still be better.

With Webpack 5’s Module Federation, the tooling is now mature enough to make micro frontends practical—not just theoretical.

Basically: start small, standardize interfaces, and automate everything.

The above is the detailed content of Micro Frontends Architecture: A Practical Implementation Guide. For more information, please follow other related articles on the PHP Chinese website!