Skip to content

CONCEPT Cited by 1 source

Entity-based page composition

Definition

Entity-based page composition is a page-assembly model in which the request-time structure of a page is a tree of typed Entities, and a separate layer chooses how each Entity in the tree is visualised. This is a deliberate inversion of Fragment-based micro-frontend assembly — where the composition primitive is a whole frontend unit — in favour of a typed, purely-data node whose visualisation is decided downstream.

The canonical production implementation on this wiki is Zalando's Interface Framework and its Rendering Engine (Source: sources/2021-03-10-zalando-micro-frontends-from-fragments-to-renderers-part-1).

The three shapes in play

  1. Entity — a typed content piece with a unique id. Zalando's named examples are Product, Collection, and Outfit. Entities are:
    • the common language services use to exchange content (the what),
    • the node type for page-layout trees (the structure).
  2. Entity tree — the server-side, personalised layout for this request. Zalando's personalisation + recommendation services pick it per customer. Example from the post: a product page with three below-article slots filled with "a collection, an outfit, and another collection."
  3. Renderer — a self-contained, reusable piece of front-end code that visualises one Entity type. The mapping from Entity to Renderer is one-to-many (one Entity type can be rendered several ways depending on placement); each Renderer handles exactly one Entity type.

Why it's useful

  • Separation of content from presentation. The personalisation system decides what the page is (the Entity tree). The presentation system decides how it looks (via Renderers). These two concerns are owned by different teams and can evolve independently.
  • Single vocabulary across services. Entities are not just page nodes — they are the data contract services use to exchange content. That collapses the combinatorial "each microservice ships its own DTOs" problem.
  • Re-use across placements. A Collection Entity can be rendered as a grid, a carousel, a hero card, or a compact-list Renderer depending on where it appears. Each Renderer is one implementation reused across many pages.
  • Personalisation is a data problem, not a frontend problem. The personalisation system only needs to emit Entity trees. It does not need to know about components, bundles, or A/B frameworks.
  • Platform-level guarantees. Because rendering is centralised, cross-cutting concerns (monitoring, consent, A/B testing, tracking, design-system versioning) can be guaranteed once, not re-wired per Renderer.

Where the data comes from

Each Renderer declaratively specifies its data dependencies via GraphQL against a central aggregation layer (UBFF-era GraphQL) (Source: sources/2021-03-10-zalando-micro-frontends-from-fragments-to-renderers-part-1). The Renderer doesn't own a backend; it just declares what data its visualisation needs for a given Entity and lets the GraphQL layer aggregate.

Design constraints this imposes

  • Entity taxonomy must be stable. Entity types become the shared vocabulary; churn in the taxonomy is expensive because it touches the personalisation service, the Rendering Engine, and every Renderer.
  • Renderers must be bounded-scope. An Outfit Renderer must render only what an Outfit Entity contains; it can't decide to also fetch an unrelated Product. That invariant is what makes the tree-walk predictable.
  • The Rendering Engine mediates. A central Rendering Engine walks the Entity tree, applies rendering rules (patterns/entity-to-renderer-mapping), and returns a Renderer tree. It becomes a load-bearing service; its failure modes affect every page.

Contrast with Fragment-based micro-frontends

Axis Fragment (Mosaic) Entity (IF)
Composition primitive whole frontend unit typed data node + Renderer
Ownership grain per Fragment (team = slot) per Renderer (team = Entity visualisation)
Stack choice per team unified (React + TS + GraphQL)
Deploy per Fragment unified platform deploy
Cross-cutting concerns re-wired per Fragment centralised in platform
Personalisation per Fragment or app-level decides Entity tree, orthogonal to rendering

(Source: sources/2021-03-10-zalando-micro-frontends-from-fragments-to-renderers-part-1.)

Seen in

Last updated · 476 distilled / 1,218 read