SYSTEM Cited by 1 source

Zalando Rendering Engine¶

What it is¶

The Rendering Engine is the runtime core of Zalando's Interface Framework. It is a Node.js backend service and a browser runtime that, for any given request, resolves a tree of Entities and transforms it into a tree of matching Renderers to produce the page the customer sees (Source: sources/2021-03-10-zalando-micro-frontends-from-fragments-to-renderers-part-1).

It sits at the centre of the IF architecture:

  GraphQL API ──→ Rendering Engine ──→ HTML + hydrated React
                  (Node.js server;
                   browser runtime)
                  uses:
                  - rendering rules (Entity → Renderer)
                  - Zalando Design System
                  - Renderers contributed by feature teams

What it does¶

Per the Part 1 post (Source: sources/2021-03-10-zalando-micro-frontends-from-fragments-to-renderers-part-1):

Receives an Entity tree whose structure is chosen by Zalando's Recommendation System (or other personalisation services) for this specific request and customer. An example from the post: a product page's in-article slots get filled with "a collection, an outfit, and another collection" chosen server-side.
Applies rendering rules — a declarative mapping from Entities to Renderers — to pick how each Entity in the tree should be visualised. The same Entity type can map to several Renderers depending on placement (an Outfit Entity might render as a main view, or as a card inside a Collection).
Invokes each Renderer, a self-contained piece of React that declares its GraphQL data dependencies and pulls from the GraphQL aggregation layer.
Renders via the Zalando Design System, which means the Rendering Engine takes over component version management and client bundle-size optimisation across Renderers — feature teams do not hand-tune either.

Hybrid rendering modes¶

A single Rendering Engine can serve three kinds of view configuration (Source: sources/2021-03-10-zalando-micro-frontends-from-fragments-to-renderers-part-1):

Mosaic Template only — legacy path; view is composed entirely of Mosaic Fragments.
Mixed — view contains Renderers and Fragments.
Renderers only — the modern IF path.

This hybrid capability is the migration load-bearer: it let Zalando swap Fragments for Renderers incrementally while keeping a single serving substrate. By March 2021, ~90% of traffic is served through the Rendering Engine, with the residual hybrid-mode tail mostly Mosaic-era Fragments not yet rewritten.

Why it runs in both Node.js and the browser¶

The post names the Rendering Engine explicitly as running "in Node.js and the browser" (Source: sources/2021-03-10-zalando-micro-frontends-from-fragments-to-renderers-part-1). That is a universal-rendering shape (see concepts/universal-rendering): the same tree-resolution and Renderer-invocation logic executes server-side to produce the initial HTML response, and client-side to resume rendering, hydrate, and re-render as the Entity tree or personalisation state changes. Keeping one Engine on both sides is what makes the "Renderer" a single unit that contributors write once and trust to run in both environments.

Known gaps (Part 1 post)¶

The Part 1 post names the Rendering Engine but does not describe:

the rendering rules language / DSL beyond "declarative set of layout rules",
whether it supports streaming SSR (concepts/streaming-ssr) or classic SSR,
the caching strategy (per-Renderer output cache? per Entity subtree?),
failure isolation across Renderers — if one Renderer throws, what does the page do?
the concurrency / backpressure model of the Node.js server,
the exact hot path for a page with 10+ Renderers.

These are flagged for upcoming posts in the series.