Skip to content

PATTERN Cited by 1 source

Demo harness for SDUI rendering

Problem

In an SDUI system, the authors of new screens (typically web developers) need to iterate on:

  • The JSON payload that describes a screen.
  • The server-side logic that produces that JSON for a given route / request context.
  • The rendering behaviour of the client runtime for the specific component tree they're authoring.

But the client runtime lives inside the full mobile app — Zalando iOS + Android, in Appcraft's case — which means naïve iteration requires:

  • Building a full iOS or Android binary (minutes per build).
  • Signing certificates + install process.
  • Navigating through the app shell to the target screen.
  • Not being able to point at a local development server.

These are inner-loop delays measured in tens of minutes per change.

Pattern

Build a stripped-down companion demo app that:

  1. Contains only the SDUI runtime + its primitives, not the full app shell.
  2. Exposes a URL address bar as the single input.
  3. Accepts any endpoint that emits SDUI JSON — including localhost URLs pointing at the developer's laptop.
  4. Renders the returned screen in isolation — no navigation, no shared app state, no analytics / tracking.

The developer:

  • Runs their server-side renderer locally.
  • Opens the demo app on a simulator / device.
  • Types http://localhost:XXXX/myscreen into the address bar.
  • Sees the current screen output; edits server code; re-requests.

Inner-loop latency drops to "server reload + app refetch" — seconds.

Appcraft's implementation: Appcraft Browser

Appcraft Browser is the canonical instance of this pattern (Source: sources/2024-05-15-zalando-transitioning-to-appcraft-evolution-of-zalandos-server-driven-ui-framework):

"We developed a demo app named the Appcraft Browser, featuring an address bar where any URL emitting appcraft screen JSON can be provided as input. The screen definition is then rendered in an isolated environment with only the bare minimum dependencies, facilitating faster development without the need to build the entire app. This tool allows web developers to insert a local host URL and test their development seamlessly while working on the renderer."

Pair with a production-context testing technique

Demo harnesses sacrifice production-fidelity for speed. Pair them with a technique that tests in the real app, even if slower: patterns/pr-deployed-renderer-testing-in-debug-app — deploy renderer change to staging via PR, pin the PR number in the debug build of the real app, exercise end-to-end. The Appcraft team uses both.

  • Demo harness — inner-loop, isolated, localhost-friendly.
  • PR-debug app — integration-loop, full-app, staging- deployed.

What goes into the demo harness

  • The SDUI client runtime (parser, primitive implementations, Elm update loop, action dispatcher).
  • The Flex layout layer (Texture-Flex / Litho-Flex in Appcraft's case).
  • Minimal shell: splash, address bar, a "render this URL" button.
  • Developer affordances: error/log visibility, state inspector, JSON payload viewer, re-render button.

What to leave out

  • Authentication.
  • Analytics.
  • Push notifications.
  • Complex navigation.
  • Full app dependency tree (including anything that requires signing into the real app).

Keeping the dependency surface minimal is the entire point — both for build speed and so the harness isolates SDUI bugs from app-shell bugs.

Adjacent dev-tool shapes

  • Storybook — the web equivalent: render individual components in isolation with controlled props, independent of the full app. SDUI demo harness is Storybook one altitude up: render whole server-authored screens, not individual components.
  • React Native Playground / Expo Go — lets you render arbitrary React Native code without building a full app. Same idea, different runtime.
  • GraphiQL / Playground for GraphQL APIs — point-at-an- endpoint + interactive query.

Anti-patterns

  • Embedding the demo harness inside the main app under a debug flag. Defeats the purpose — build times + app-shell dependencies remain.
  • Harness that silently supplies missing dependencies (fake auth tokens, fake feature flags). Obscures real failures and diverges from production behaviour. Better to fail loud on missing context.
  • Harness with app-specific navigation stack built in — now it's a second app, not a harness.

Seen in

Last updated · 550 distilled / 1,221 read