SYSTEM Cited by 1 source

Zalando Interface Framework (IF)¶

What it is¶

Interface Framework (IF) is Zalando's second-generation frontend platform for the core customer-journey pages of zalando.com. Design started in 2018; by March 2021 IF serves around 90% of traffic and is the replacement target for the first-generation Project Mosaic micro-frontend architecture (Source: sources/2021-03-10-zalando-micro-frontends-from-fragments-to-renderers-part-1).

IF is the unifying layer over:

a monorepo-hosted React + TypeScript codebase (see concepts/monorepo),
a central GraphQL data aggregation layer shared across surfaces (see systems/zalando-graphql-ubff for the same era's backend-for-frontend story),
a single design system for look-and-feel, accessibility, and component versioning,
a Node.js-plus-browser Rendering Engine that resolves a tree of Entities into a tree of matching Renderers.

Why it replaced Mosaic¶

Mosaic composed pages from Fragments owned by different teams. That shipped fast iteration from 2015 onward but by 2018 had accumulated four recurring pain points (Source: sources/2021-03-10-zalando-micro-frontends-from-fragments-to-renderers-part-1):

Tech-stack divergence across Fragments — different bundlers, versions, deploy cadences — visible as inconsistent UX.
High entry barrier for feature teams: to add a feature you had to stand up and operate your own Fragment (frontend
backend), discover and integrate data sources, and reimplement UI, tracking, and A/B testing.
No centralised UX guarantees — design language, a11y, and component versioning drifted per team.
Duplicated cross-cutting concerns — monitoring, consent, A/B testing, tracking were each re-wired per Fragment.

IF is the inversion: unify the tech stack, centralise deployment/operation, and expose Renderers as the unit feature teams contribute.

Architectural shape¶

                     ┌──────────────────────┐
                     │   GraphQL API        │  data aggregation
                     │ (incl. personalization,│  (UBFF-era layer)
                     │  Recommendation Sys) │
                     └──────────┬───────────┘
                                │
         ┌──────────────────────▼──────────────────────┐
         │            Rendering Engine                  │
         │   Node.js backend  +  browser runtime        │
         │   resolves Entity tree → Renderer tree       │
         └──────────┬───────────────────────┬──────────┘
                    │                       │
             Rendering rules          Design system
             (Entity → Renderer       (components,
              mapping; declarative)   versioning, a11y)
                    │                       │
           ┌────────▼──────┐         ┌──────▼──────┐
           │ Renderer: A   │   ...   │ Renderer: N │   self-contained;
           │ (outfit card) │         │(collection  │   GraphQL-declared
           └───────────────┘         │ carousel)   │   data deps per
                                     └─────────────┘   Entity type

The Rendering Engine can serve three hybrid view shapes during the Mosaic → IF migration (Source: sources/2021-03-10-zalando-micro-frontends-from-fragments-to-renderers-part-1):

A view that is a pure Mosaic Template using only Fragments.
A view that contains both Renderers and Fragments.
A view that is only Renderers.

This hybrid capability is what made a multi-year co-existence tractable while Mosaic Fragments were rewritten into Renderers.

Key primitives¶

Entities — canonical, typed content pieces (Product, Collection, Outfit, …) used both as the common language between microservices and as the node type for page composition. See concepts/entity-based-page-composition.
Renderers — self-contained, reusable React components that visualise one Entity type. An Entity can map to one-of-many Renderers (e.g. an Outfit rendered as a main view or a card inside a Collection). Each Renderer is the unit feature teams own. See patterns/entity-to-renderer-mapping.
Rendering rules — a declarative set of rules mapping a tree of Entities to the tree of Renderers that should visualise it. The Rendering Engine executes them at request time.

Platform capabilities built in¶

Feature teams do not re-wire these per Renderer; IF provides them centrally:

Integrated monitoring — every view auto-connects to internal monitoring so disruptions in reporting or personalisation are caught at the platform layer.
Orchestrated A/B testing — integration with Zalando's Octopus experimentation platform so experiments are implemented in a few lines of code, auto-validated, auto-tracked, and batched to keep per-Renderer A/B-test call overhead low (Source: sources/2021-03-10-zalando-micro-frontends-from-fragments-to-renderers-part-1).
Deployment previews — any open pull request is previewed in an environment connected to production endpoints with 100% production routing, gated to authenticated developers. Distinct from staging; closer to "prod, but your PR."
Centralised design system — look & feel, a11y, and component-version management are done by the Rendering Engine so client bundle size stays optimised.
Performance quality gates (see patterns/page-performance-quality-gates):
- Lighthouse CI for per-page performance + a11y assertions on every PR.
- Bundle Size Limits — automatic per-Renderer bundle size diff on every PR.
- Client Metrics — built-in layer reporting Web Vitals and custom metrics for every page.

Organisational effect¶

Teams remain feature teams with embedded frontend engineers, but they now work in a monolithic repository with a unified, automated environment (Source: sources/2021-03-10-zalando-micro-frontends-from-fragments-to-renderers-part-1):

Teams develop features and UI elements inside Renderers, which are associated with Entities that make up the page semantic.
Ownership lines inside Renderers are blurred by design — multiple teams contribute to most Renderers, and a set of contribution guidelines governs the shared codebase.
Modern stack is aligned across teams: React + TypeScript + GraphQL, centralised server infrastructure, shared release process, shared monitoring and alerting.

Numbers (as of March 2021)¶

~90% of zalando.com traffic served via Interface Framework.
Design started 2018. Three years of production iteration.
First-generation Mosaic introduced 2015; IF co-exists with Mosaic via hybrid Rendering-Engine modes.
Monorepo + unified deploy/ops (exact contributor counts unstated in the Part 1 post).

Known gaps (Part 1 post)¶

Rendering rules DSL is described as "a declarative set of layout rules" but its shape, expressiveness, and extensibility are not described. Promised in upcoming posts.
Rendering Engine internals — render scheduling, streaming, SSR-vs-CSR boundary, caching, failure isolation across Renderers, and the exact Node.js hot path are not covered. Promised in upcoming posts.
Entity taxonomy size is undisclosed ("a reasonably small amount of content pieces"). No count of Entity types.
Migration economics — the cost of rewriting Mosaic Fragments into Renderers is not quantified beyond "~90% of traffic" as of March 2021.