What is microfrontend?

A microfrontend is an architectural style for building web applications where the UI is split into small, independent pieces-called micro‑frontends-each owned by a separate team. Each piece is a self‑contained front‑end module (like a mini‑app) that can be developed, deployed, and updated on its own, then assembled together in the browser to form the full user interface.

Let's break it down

  • Monolith vs. micro‑frontend: In a monolithic front‑end, the whole UI lives in one codebase and is released as a single unit. In a micro‑frontend, the UI is divided into multiple smaller apps.
  • Team ownership: Each team owns a specific feature or section (e.g., search bar, shopping cart) and can choose its own framework or tooling.
  • Integration: At runtime, a container (or shell) loads the individual micro‑frontends, often via JavaScript modules, iframes, or web components.
  • Independent deployment: Because they are separate, a team can push updates to its micro‑frontend without waiting for other teams.

Why does it matter?

  • Speed: Teams can work in parallel, reducing bottlenecks and speeding up feature delivery.
  • Flexibility: Different parts of the app can use different technologies (React, Vue, Angular) without forcing a single stack.
  • Scalability: Large organizations can scale development by adding more teams, each responsible for a slice of the UI.
  • Resilience: If one micro‑frontend fails, the rest of the app can continue to work, improving overall stability.

Where is it used?

  • E‑commerce platforms where the product catalog, checkout, and user profile are built by separate teams.
  • Enterprise SaaS dashboards that combine analytics, reporting, and admin panels from different squads.
  • Media sites that integrate a news feed, video player, and comment system, each managed independently.
  • Large corporate intranets where HR, finance, and IT modules are developed and deployed separately.

Good things about it

  • Enables true independent development and deployment.
  • Reduces coordination overhead between teams.
  • Allows technology heterogeneity-teams can pick the best tool for their feature.
  • Improves fault isolation; a bug in one micro‑frontend doesn’t crash the whole app.
  • Facilitates gradual migration from an old stack to a new one, piece by piece.

Not-so-good things

  • Adds complexity in routing, shared state, and styling across multiple micro‑frontends.
  • Can lead to larger bundle sizes if not managed carefully, because each piece may bring its own dependencies.
  • Requires a robust integration layer (shell) to load and coordinate the pieces.
  • Potential inconsistent user experience if teams don’t align on design guidelines.
  • More operational overhead for monitoring, testing, and versioning many independent deployments.