Skip to content

CONCEPT Cited by 1 source

Deep-link to screen-config resolution

Definition

In a server-driven UI system, a deep-link (URL that opens a specific app screen) is resolved into a screen configuration through an indirection middleware rather than a hardcoded client-side route table. The pipeline:

  deep-link URL  →  routing middleware  →  API endpoint  →  screen JSON
  (client issues)  (server-side)         (server-side)     (client renders)

The client's deep-link resolver has no hardcoded knowledge of which screens exist; it only knows how to:

  1. Parse a deep-link into a canonical form.
  2. Call the routing middleware with that form.
  3. Take back an API endpoint to hit for screen JSON.
  4. Render whatever screen JSON returns.

Adding a new screen therefore becomes a server-side configuration change, not a client release.

How Zalando Appcraft implements it

Appcraft uses this mechanism to avoid shipping new client builds every time a new screen is introduced (Source: sources/2024-05-15-zalando-transitioning-to-appcraft-evolution-of-zalandos-server-driven-ui-framework):

"We've introduced a middle-man component that takes a deep-link and converts it into an API request that our framework can understand. This way, every time a new screen is needed, our stakeholders simply align on the deep-link structure and update the configuration according to the agreed-upon contract. With these adjustments in place, the setup is complete. The next step involves the renderer, which will then interpret the updated configuration and render the new screen accordingly."

The post includes a "deeplink-resolution-sequence-diagram" referenced visually in the original but only by link.

The contract splits:

  • Deep-link structure — agreed between the clients and the platform team. The clients implement parsing once. New deep-link forms would require a client release; new deep- link instances under existing forms do not.
  • Deep-link → API route table — lives on the server. Can be updated any time. A new screen = add a new entry.

This split is important: the client commits to understanding a family of deep-link shapes, not specific URLs.

Why this is necessary for same-day UI delivery

Without deep-link indirection, every new screen would need at minimum:

  • A new hardcoded route on each client.
  • A client release to deploy that route.
  • Synchronisation of route versions across iOS + Android.

With deep-link indirection, only the server needs to change. This is the mechanism by which concepts/same-day-ui-delivery is achievable — the other half (after primitives + server-owned versioning) of what makes Appcraft's no-release cadence work.

  • App-internal deep-links — zalando://stories/123 maps to an Appcraft screen via the middleware.
  • External deep-links — web URLs https://…/stories/123 opened via universal links trigger the same middleware path.
  • Push-notification taps — same pipeline; the push payload is a deep-link.

Contrast with hardcoded route tables

Property Hardcoded routes Deep-link indirection
New screen Client release Server config change
Client-side route registry Yes, per route None
Deep-link format evolution Client release Server deploy
Route-table versioning Per client Single server table
Broken-link triage Client logs Centralised

Seen in

Last updated · 550 distilled / 1,221 read