Skip to content

CONCEPT Cited by 1 source

Micro-frontends

Definition

Micro-frontends is the application of microservice-style ownership to the frontend: a page or application is composed at runtime from independently owned, independently developed, and (usually) independently deployed frontend units — commonly called fragments or micro-apps — each delivered by a different team.

The goal mirrors backend microservices: let many teams ship to the same customer surface in parallel without coordinating on a single monolith build or deploy.

Canonical runtime shape

The reference shape — documented publicly as Project Mosaic and used in production at Zalando from 2015 — is (Source: sources/2021-03-10-zalando-micro-frontends-from-fragments-to-renderers-part-1):

  1. A page template with named slots.
  2. Each slot filled by a Fragment — a frontend bundle plus, usually, its own backend service — owned by one team.
  3. A composition layer (Mosaic's Tailor, in this case) that stitches Fragments into one response at request time.

Fragments may be server-rendered, client-rendered, or hybrid.

Why teams choose it

  • Independent deploys — a team ships its Fragment without coordinating a site-wide release.
  • Stack autonomy — each Fragment can use a different framework, bundler, or language if the composition contract is respected.
  • Contribution scale — larger contributor count (100+ teams) becomes tractable at the page-composition layer.
  • Conway's-Law-respecting — Fragment boundaries can be drawn to match team boundaries (see concepts/conways-law).

Structural pain points (Zalando 2018 retrospective)

Zalando's own Part 1 post is a clear enumeration of what micro-frontends buy you and what they cost, based on three years of Mosaic in production (Source: sources/2021-03-10-zalando-micro-frontends-from-fragments-to-renderers-part-1):

  1. Tech-stack divergence across Fragments leads to inconsistent UX and cross-team collaboration difficulty.
  2. High entry barrier to contribute: to add a feature you must build and operate your own Fragment (frontend and backend), discover and integrate every data source, and reimplement UI, tracking, and A/B testing.
  3. No centralised UX guarantees — design language, a11y, and component versioning drift per team.
  4. Duplicated cross-cutting concerns — monitoring, consent, A/B testing, tracking all get re-wired per Fragment.

These pain points map back to a core structural choice: each Fragment owns a whole frontend stack, so every cross-cutting concern has N implementations. Micro-frontends trade platform consistency for team autonomy.

The entity-based alternative

A response to these pains — Zalando's Interface Framework — reframes the composition primitive. Instead of Fragments as independently deployed mini-apps, the unit becomes a Renderer: a React component visualising a single Entity (Product, Collection, Outfit). The Rendering Engine is one unified service that picks renderers at request time based on declarative rules. See concepts/entity-based-page-composition and patterns/entity-to-renderer-mapping.

This is structurally a step back toward monolith at the platform layer while keeping feature-team ownership at the Renderer layer — trading Fragment-level autonomy for a smaller contribution unit with centralised platform capabilities (monitoring, A/B testing, design system, performance gates).

When micro-frontends still make sense

  • Contribution velocity dwarfs UX-consistency cost (very large org, independent user surfaces).
  • Strict isolation required between Fragments (e.g. third-party-rendered content).
  • No single team can own and evolve a platform layer fast enough to keep up with feature teams.

When those conditions don't hold, a unified-rendering platform with a smaller contribution unit (like IF) tends to win.

Seen in

Last updated · 476 distilled / 1,218 read