What Are Micro Frontends?
Micro frontends have emerged as a powerful architectural pattern for scaling frontend development across organizations. This page defines the concept, traces its evolution, and establishes the principles that distinguish it from related approaches.
Definition
Section titled “Definition”Micro frontends extend the principles of microservices to the frontend layer. Just as backend microservices decompose a monolithic server into independently deployable services owned by different teams, micro frontends decompose a monolithic user interface into smaller, independently deployable applications—each owned end-to-end by a dedicated team.
The key insight: if your backend benefits from domain boundaries, technology flexibility, and independent release cycles, your frontend can benefit from the same. A micro frontend is a self-contained slice of the user interface that:
- Encapsulates a vertical slice of business capability (e.g., product catalog, shopping cart, user profile)
- Can be developed, tested, and deployed independently
- Is composed at runtime or build time with other micro frontends to form the full application
Unlike a shared component—which is a building block used by many teams—a micro frontend represents an entire feature area. Think of it as a mini-application with its own routing, state management, and API integrations. The “micro” refers to scope and ownership, not necessarily to the amount of code.
Historical Evolution
Section titled “Historical Evolution”To appreciate why micro frontends exist, it helps to understand how frontend architecture has evolved.
Monolithic Frontends
Section titled “Monolithic Frontends”For years, most applications consisted of a single frontend codebase. Every team contributed to the same repo, shared the same build pipeline, and released together. As applications grew, this model led to:
- Coordination overhead between teams: Release planning required synchronizing multiple teams. A bug in one area could delay a feature in another.
- Long release cycles: Everyone waited for everyone else. Weekly or bi-weekly releases became the norm, even when individual features were ready sooner.
- Tight coupling and merge conflicts: Shared components and global state created dependencies that made isolated changes difficult. Git merges became a source of friction.
- Difficulty adopting new technologies incrementally: Upgrading React or introducing a new state library affected the entire application. Big-bang migrations were often the only option.
Component Libraries and Design Systems
Section titled “Component Libraries and Design Systems”The next step was to extract reusable UI building blocks into component libraries and design systems. Teams could share buttons, cards, and patterns without duplicating code. This improved consistency and developer experience—but it did not solve the core problem: teams still shipped one monolithic application. A change in one area could block releases across the board.
Micro Frontends
Section titled “Micro Frontends”Micro frontends take the decomposition further. Instead of sharing only components, teams own entire vertical slices of the UI. Each slice is a separate application with its own lifecycle. The full user experience is assembled by composing these slices—often using techniques like client-side composition (JavaScript loads and mounts micro frontends in the browser), server-side composition (a backend assembles HTML fragments), or edge composition (CDN or edge runtimes compose at the edge). For details on how composition works in practice, see Composition Strategies.
Core Principles
Section titled “Core Principles”Micro frontend architecture rests on several foundational principles:
Independence
Section titled “Independence”Each micro frontend should be independently developable, testable, and deployable. Teams work in isolation, with minimal dependencies on other teams’ release schedules. This reduces coordination costs and accelerates delivery. Independence does not mean teams never collaborate—they share APIs, events, and design tokens—but they do not block each other’s releases.
Technology Agnosticism
Section titled “Technology Agnosticism”Teams can choose the right technology for their domain. The product team might use React, the checkout team Vue, and the legacy catalog team Angular—all within the same user experience. This “polyglot frontend” enables incremental technology upgrades and avoids forcing a single framework across the entire organization. Technology choices are made at the team level, aligned with team expertise and domain needs.
Isolated Failure
Section titled “Isolated Failure”When one micro frontend fails or underperforms, it should not bring down the entire application. Proper boundaries and fallbacks (e.g., error boundaries, lazy loading, graceful degradation) limit blast radius and improve resilience. Users may see a degraded experience in one area while the rest of the application continues to function.
Autonomous Teams
Section titled “Autonomous Teams”Teams own their slice end-to-end—from UI to API integration. They define their own development practices, testing strategies, and deployment schedules. This aligns with the “you build it, you run it” philosophy popularized by microservices. Autonomy fosters ownership and accountability: teams are responsible for their feature’s performance, reliability, and user experience.
How They Work at a High Level
Section titled “How They Work at a High Level”In a micro frontend architecture:
- Different teams own different parts of the UI. Each team is responsible for a vertical slice aligned with business capability.
- Composition happens at runtime or build time. A shell application (or “host”) loads and assembles micro frontends. The composition strategy—client-side, server-side, or edge—determines when and where this happens. See Composition Strategies for a deeper dive.
- Communication occurs across boundaries. Micro frontends may need to share state, events, or navigation. Common patterns include custom events, a shared event bus, or URL-based routing.
The result: multiple independently deployable frontends that appear to users as a single, cohesive application.
The Shell (Host) Application
Section titled “The Shell (Host) Application”A common pattern is the shell or host application—a minimal container that handles routing, layout, and loading of micro frontends. The shell does not contain business logic; it orchestrates composition. Each micro frontend is loaded when the user navigates to its route or when it is needed for the current view. The shell ensures a consistent navigation structure, header, footer, and loading experience.
How Micro Frontends Differ From Related Concepts
Section titled “How Micro Frontends Differ From Related Concepts”| Concept | Relationship |
|---|---|
| Component libraries | Component libraries provide reusable UI pieces. Micro frontends are full applications; they may use component libraries internally, but they emphasize ownership of vertical slices, not shared horizontal components. |
| Monorepos | A monorepo is a version-control strategy—one repo, many packages. Micro frontends can live in a monorepo or in separate repos. Monorepos do not imply independent deployment or team autonomy. |
| Design systems | Design systems define visual and interaction patterns. Micro frontends can adopt a shared design system for consistency while remaining independently deployable. |
| iframes | iframes can technically host separate UIs, but they introduce isolation challenges (styling, performance, accessibility) and are rarely the preferred composition mechanism for modern micro frontends. |
Understanding these distinctions helps avoid conflating micro frontends with adjacent practices. Micro frontends are about architectural decomposition and ownership; component libraries and design systems are about reuse and consistency; monorepos are about version control structure.
Relationship to Microservices
Section titled “Relationship to Microservices”Micro frontends mirror microservices on the backend. A typical setup:
- Backend: Product API, Cart API, Checkout API—each owned by a different team.
- Frontend: Product micro frontend, Cart micro frontend, Checkout micro frontend—each team owns both the UI slice and its corresponding API.
This end-to-end ownership reduces handoffs and keeps domain boundaries consistent across the stack. The frontend and backend evolve together within each team’s scope. When the checkout team needs a new payment method, they implement both the API and the UI without coordinating with the product or cart teams. This reduces the cognitive load of understanding the entire system and accelerates feature delivery.
Conceptual Example: E-Commerce
Section titled “Conceptual Example: E-Commerce”Consider an e-commerce site with three teams:
- Product Team owns the product catalog—browsing, search, and product detail pages.
- Cart Team owns the shopping cart—add to cart, edit quantities, remove items.
- Cart Team also owns a cart widget/mini-cart displayed in the header.
- Checkout Team owns the checkout flow—shipping, payment, order confirmation.
Each team develops and deploys independently. The shell application composes these into one experience: users browse products (Product), add to cart (Cart), and complete checkout (Checkout) without perceiving the seams. Routing and shared state (e.g., cart count) are coordinated across boundaries—perhaps via a shared event bus or URL parameters.
The cart widget in the header is a notable pattern: it belongs to the Cart team but appears on every page. The shell reserves a slot for it; the Cart micro frontend renders into that slot when loaded. This illustrates that micro frontends are not strictly page-based—they can be embedded in different layouts and contexts.
For a deeper analysis of the benefits and trade-offs of this approach, see Benefits and Trade-offs.
Summary
Section titled “Summary”Micro frontends extend microservices to the frontend, enabling independent teams to own vertical slices of the UI, choose their own technologies, and deploy autonomously. They differ from component libraries, monorepos, design systems, and iframes—each of which addresses a different concern. The key is composition: assembling independently developed frontends into a cohesive whole at runtime or build time.
Go Deeper in the Book
This topic is covered in depth in Chapters 1-2 of Micro Frontends Architecture for Scalable Applications, with detailed examples, diagrams, and production-ready patterns.