Skip to content

Deployment Scenarios

VDP defines what a view descriptor says and how it reaches a client (Specification Section 4). It deliberately does not define where template source text comes from: a template URL is an identifier first — a stable name and cache key — and a fetchable location only secondarily (Section 6.3).

The four deployments below are all fully conforming, and each pairs freely with any transport — Link header, inline _view/_views, View-Template, or well-known discovery. Dashed elements are outside the protocol: VDP names templates; it never dictates where they live.

Templates bundled with the app

Diagram: an API sends data plus a view descriptor to the VDP client inside a mobile or desktop app, which looks templates up by URL in the bundle shipped with the app — no fetch Diagram: an API sends data plus a view descriptor to the VDP client inside a mobile or desktop app, which looks templates up by URL in the bundle shipped with the app — no fetch

Mobile and desktop apps ship their templates inside the application package. The descriptor's template URLs act as lookup keys into that bundle, so rendering needs no template network traffic at all, and template updates ship with the app. Templates inside the app's own trust boundary are exempt from the Section 10 network rules.

A BFF resolves server-side

Diagram: a browser requests a page from a BFF; the BFF's VDP client gets data plus a view descriptor from the API, resolves templates from a local store or cached fetches, and returns rendered HTML — no VDP in the browser Diagram: a browser requests a page from a BFF; the BFF's VDP client gets data plus a view descriptor from the API, resolves templates from a local store or cached fetches, and returns rendered HTML — no VDP in the browser

The backend-for-frontend is the VDP client (Section 7.5): it calls the API, resolves the descriptor against its local template store — or fetches and caches — and returns finished HTML. The browser never sees VDP.

Templates shipped with the page

Diagram: the API sends data plus a view descriptor to a client script in the browser page, which matches template URLs against template elements delivered with the HTML Diagram: the API sends data plus a view descriptor to a client script in the browser page, which matches template URLs against template elements delivered with the HTML

The initial HTML delivers the templates themselves — for example as <template> elements. A small client script matches each descriptor's template URLs against that in-page registry, so later API responses can re-template parts of the page without any further template requests.

Templates fetched remotely

Diagram: the API sends data plus a view descriptor to a client, which fetches templates by URL over HTTPS from a template server or CDN — cached, allowlisted, integrity-checked Diagram: the API sends data plus a view descriptor to a client, which fetches templates by URL over HTTPS from a template server or CDN — cached, allowlisted, integrity-checked

The fully networked deployment: the client fetches each template URL over HTTPS from a template server or CDN, caching per ordinary HTTP semantics (Section 5.2). Everything in Section 10 applies — the allowlist source chain, HTTPS, and integrity verification. This is the deployment the Go demo implements end to end.

These sources also compose: a client MAY consult several in order — an app bundle first, say, with a remote fetch for templates the bundle lacks. In every case the absolute template URL (Section 5.4) is the template's identity.