What Are Micro Frontends and When Should You Use Them

Micro frontends split a web product into independently deployable UI pieces—often owned by different teams—while still presenting a single experience in the browser. The idea mirrors microservices on the backend: smaller blast radius, parallel releases, and technology choices per slice instead of one giant SPA repository.

Whether that tradeoff is worth it depends less on buzzwords than on your team topology and release pain. This guide walks through architectures, integration styles, and the failure modes that catch teams after the first successful pilot.

The problem micro frontends try to solve

In a monolithic frontend, every team ships through the same build pipeline. A checkout redesign waits on a unrelated settings-page refactor. Shared state and routing become political battlegrounds.

Micro frontends push ownership to the edges:

• The search team ships search results UI on its own cadence.
• The account team owns profile and billing shells.
• A platform team provides the host shell, design tokens, and authentication.

The user still sees one site; operations see multiple repositories and deployment pipelines.

Core integration approaches

Build-time composition

Packages are npm dependencies assembled at compile time. Team B imports Team A’s published component library.

Pros: Simple performance story, strong typing across packages.
Cons: You redeploy the shell to pick up child updates—so independence is partial.

Best when teams are small or you mainly want modular code without separate deployables.

Run-time integration via JavaScript

The host loads remote bundles at runtime (Module Federation in webpack/Rspack, import maps, or custom loaders). Each micro frontend exposes entry points; the shell stitches routes.

Pros: True independent deploys; teams can use different framework versions in theory.
Cons: Runtime complexity, version skew, shared dependency deduplication, harder local dev.

This is what people usually mean by “micro frontends” in large enterprises.

Server-side composition

Edge or origin servers assemble HTML fragments (SSI, ESI, or framework-specific islands). Each team serves HTML partials; the CDN stitches pages.

Pros: Fast first paint, SEO-friendly when done well.
Cons: Infrastructure sophistication; less common in pure SPA shops.

Good for content-heavy sites mixing marketing pages and app shells.

iframe isolation

Each micro frontend runs in an iframe with postMessage bridging.

Pros: Hard isolation—styles and JS cannot leak.
Cons: UX friction (routing, focus, accessibility), performance overhead.

Use sparingly for legacy embeds or untrusted third-party widgets.

Routing and the shell application

The shell (container app) typically owns:

• Top-level routing and authentication gates
• Global layout, navigation, and analytics hooks
• Cross-cutting concerns: i18n, feature flags, error boundaries

Child apps register routes like /search/* or mount into DOM slots (<div id="mf-checkout"></div>). Contract tests between shell and children prevent silent breakage when remote URLs change.

Document version compatibility: which shell versions accept which remote versions, and how rollbacks work.

Shared design without shared chaos

Design systems save micro frontends from looking like five different products.

Practical rules:

• Publish a token package (color, spacing, typography) consumed by all teams.
• Prefer web components or framework-agnostic primitives for buttons and forms when teams mix React, Vue, or Svelte.
• Avoid sharing application state libraries across team boundaries unless you have a platform guild maintaining them.

CSS isolation strategies include CSS modules, shadow DOM, or build-time scoping. Global reset.css wars are a sign you skipped tokens.

Communication between micro frontends

Keep coupling loose:

• URL and query parameters for shareable state
• Custom events on window for fire-and-forget notifications
• Small shared event bus owned by platform—with schemas and deprecation policy

Do not replicate a Redux store across team boundaries unless you enjoy distributed monoliths with extra network hops.

Testing and local development

Invest early in:

• Contract tests for each remote’s exposed modules
• Mock shells so child teams develop without running the entire enterprise stack
• Preview environments that pin compatible remote versions

Module Federation’s remotes configuration should point to staging URLs in CI, not production, during integration tests.

When micro frontends are a mistake

Skip or delay if:

• You have one team under ten engineers—monorepo + feature folders is simpler.
• Your pain is slow builds, not organizational boundaries—fix tooling first (caching, incremental TypeScript, split CI).
• You cannot staff a platform team to own the shell, observability, and dependency alignment.

Micro frontends tax coordination. They pay off when coordination taxes in a monolith are already higher.

Observability and performance

Each remote is another failure domain. Standardize:

• Real user monitoring tags per micro frontend name
• Error boundaries that report which remote threw
• Budgets for JavaScript bytes per route

Lazy-load remotes on route activation. Prefetch the next likely remote only when metrics justify it.

Migration path from a monolith

1. Carve out a vertical slice (e.g., marketing footer or help center) with clear APIs to the backend.
2. Expose it as a remote while the monolith still owns routing.
3. Move routing responsibility to the shell incrementally.
4. Delete duplicate code in the monolith only after traffic fully shifts.

Trying to split fifty screens at once usually stalls; one bounded slice proves the pipeline.

FAQ

Do micro frontends require different frameworks per team?
No. Many successful setups standardize on one framework but separate deployables. Mixed frameworks add cost; allow it only with strong platform support.

How is this different from a monorepo?
A monorepo can host multiple deployable frontends with shared tooling. Micro frontends emphasize independent deployment and team ownership, which a monorepo may or may not provide.

What about SEO?
Client-only micro frontends still face SPA SEO challenges. Prefer server composition or SSR in the shell for public pages.

Who owns authentication?
Almost always the shell. Child apps receive tokens or session context via props or secure cookies, not by reimplementing login.

Can micro frontends work with Next.js?
Yes, with multi-zone deployments or federated islands, but plan routing and caching carefully—Next’s opinions conflict with naive remote loading patterns.

Organizational cues that predict success

Micro frontends work best when Conway’s law is already pushing you toward separate backlogs. If product leadership funds stable teams around customer journeys (discover, purchase, support), giving each journey a deployable UI matches how decisions are made. If everyone still reports through one frontend manager with a single quarterly roadmap, the architecture will fight your governance.

Negotiate interface stability SLAs between teams: remotes expose versioned entry points, and breaking changes require a deprecation window measured in sprints, not hours. Platform engineers provide golden-path templates—lint rules, bundle analyzers, and starter repos—so “independent” does not mean “inconsistent.”

Celebrate early wins publicly—a faster checkout experiment shipped without redeploying the entire storefront—so stakeholders see why the integration tax exists. Without that narrative, micro frontends look like slower monoliths until the second year, when parallel releases finally compound.

Checklist before you adopt

• At least two teams feel release pain in the monolith today
• A platform squad can own the shell, CI templates, and observability baselines
• Design tokens and accessibility standards are agreed across teams
• You have a plan for version skew and rollback of remotes
• Leadership accepts slightly higher initial integration cost for faster parallel delivery later

If more than two boxes stay unchecked, fix organizational or tooling issues first; micro frontends rarely rescue a team that has not already outgrown a single-repo workflow.