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

Variants observed on wiki

Three structurally distinct composition primitives have emerged across the ingested corpus, each answering the same organisational question (let many teams ship to one surface independently) with a different runtime shape:

Variant Composition primitive Deploy topology Runtime shape Canonical example
Fragment-based Server-composed HTML fragments, each with its own backend One deploy per Fragment Server-side stitching at request time (e.g. Tailor) Zalando Mosaic
Entity → Renderer A React component per domain Entity type, inside a unified Rendering Engine One monorepo deploy for the engine + Renderers Server-side React pick-by-Entity-type with streaming SSR Interface Framework
Module-Federation remote An independently built Webpack bundle, dynamically imported at runtime One deploy per remote + one per host Browser-side host loads RemoteEntry.js + shared React singleton Zalando Logistics Portal

The variants trade off on different axes: Fragment-based gives maximum team autonomy (independent stack per Fragment) at maximum platform-consistency cost; Entity-Renderer trades Fragment-level autonomy for a unified platform layer; Module-Federation is a middle path with independent deploys but shared runtime libraries, typical at smaller scales (tens of apps, not hundreds of Renderers).

Last updated · 542 distilled / 1,571 read