Skip to content

CONCEPT Cited by 1 source

Root-entity experience resolution

Definition

Root-entity experience resolution is the specific step in Zalando's Interface Framework request lifecycle where an Experience is selected — once — for the whole request. Zalando's own words: "The first one is the Experience Resolution step. This starts very early during the root entity resolution" (Source: sources/2023-06-25-zalando-context-based-experience-in-zalando).

It is the fork point in the per-request walk: when the Rendering Engine first asks FSA what the root entity of this page is, the owning domain backend (Catalog, Search, Product) has enough context to classify the customer's intent and pick the right Experience. That choice then travels with the request through every subsequent fan-out.

Where it sits in the request lifecycle

The IF request lifecycle, per Part 1 + Part 2 + this post:

1. Skipper → Rendering Engine
     with (entity-type, entity-id)
2. Rendering Engine → FSA
     → Catalog / Search / Product backend
       ⇒ root entity resolution
       ⇒ EXPERIENCE RESOLUTION    ← this concept
       ⇒ returns (root entity, resolved experience name)
3. Rendering Engine stores experience name in request state
4. Recursive walk over root entity's children
     For each child: Rendering Engine → FSA
       query includes the resolved experience name
       ⇒ domain backend applies Experience's policies
       ⇒ returns data + streams HTML

Step 2 is where this concept lives. Crucially it piggybacks on root entity resolution — a step that had to happen anyway to know what page to build — rather than adding a separate pre-flight pass.

Why the root-entity step is the right place

Three architectural reasons:

  • Context is already available. The domain backend serving the root entity already parses the URL / query / filters / entity id to pick the root entity. That same parsed context is what customer intent selection needs.
  • It happens exactly once per request. Child Renderers can fan out to many GraphQL queries, but root-entity resolution happens once. Making Experience selection piggy-back on it guarantees single-resolution without needing a lock / memo.
  • Policies apply to every downstream call. The Experience resolved at root time is the one every child Renderer's backend query needs to know about. Resolving it upstream of the fan-out avoids having to thread context-recognition logic into every backend call.

Not before, not after

  • Not before root-entity resolution: the Rendering Engine doesn't know which backend owns the request until it starts resolving the root entity, so it can't ask the right backend for a rule match.
  • Not after: by the time child Renderers start querying FSA, the request state must already contain the Experience name so the child-level queries carry it. A post-root-resolution selection step would either introduce a blocking barrier before the fan-out (contradicting Part 2's non-blocking tree walk) or allow the first child queries to miss context.

Relationship to recursive entity-tree resolution

Part 2 established recursive entity-tree resolution — the Rendering Engine walks the Entity tree depth-first, streaming HTML as soon as each Renderer is ready. Root-entity experience resolution fits cleanly into that walk: the root node is where the Experience is picked, every recursive step inherits it via the Rendering Engine request state.

Seen in

Last updated · 550 distilled / 1,221 read