DocumentationBuild. Deploy. Operate.
DocsDeployment

Utilising the Delta-Flow via an API Call

On this page 4 sections

Once the browser substrate is present on a page, any same-origin GET request automatically rides the QSCS delta flow. Your application does not implement, or even need to know about, the delta protocol. You call an ordinary endpoint and the substrate handles the compression and reconstruction underneath.

In one sentence. Inject the substrate, keep your reads same-origin GET, and repeat calls to the same endpoint return as small per-client diffs, while fetch().json() still gives you the full response.

1. How it works

The substrate patches fetch and XMLHttpRequest. For each same-origin GET it attaches a stable per-client identifier and, once it already holds a cached copy of that URL, signals that it can accept a delta. QSCS then returns only what changed since the client last saw it, and the substrate reconstructs the full body from its cached copy before handing it to your code.

The first request for any URL is always returned in full, there is nothing to diff against yet, and cached. Every subsequent request comes back as a diff, or as an empty no-change response when nothing has moved. Because the diff is computed per client, two visitors polling the same endpoint each receive a diff against their own last-seen state.

2. What you need to do

Very little, the behaviour is automatic once the substrate is on the page. The requirements are simply:

  • Inject the substrate, see Browser Substrate & WASM Bootstrap. When it is injected on every page, the delta flow applies to every same-origin request.
  • Read with a same-origin GET. Cross-origin requests and non-GET methods pass straight through, uncompressed.
  • Return a stable, cacheable response. Deterministic output for a given URL diffs best. Avoid Cache-Control: no-store, and strip volatile cache-busting query parameters server-side so repeat calls line up against the same baseline.
  • Keep the path in scope. Paths marked as excluded in the client configuration opt out of the flow, leave your API endpoints out of that exclusion list.

3. Example

On the client there is nothing QSCS-specific to write, a normal fetch is enough:

const res  = await fetch("/api/report?range=24h");
const data = await res.json();   // the full, reconstructed response
render(data);

On the server, expose a plain GET that returns a deterministic body and does not forbid caching:

header("Content-Type: application/json; charset=utf-8");
// no "no-store" — let QSCS cache and diff this response
echo json_encode($result);

4. Verifying it is working

Open your browser developer tools and watch the response headers as the page polls. The first load returns a full response; subsequent calls to the same endpoint should report that they returned a diff, or that nothing changed, with almost no data transferred. If you only ever see full responses, confirm that the substrate is injected, that the request is a same-origin GET, and that the endpoint is not excluded.

Do not implement the protocol yourself. The substrate owns delta negotiation and reconstruction end to end. Reading the QSCS response headers and attempting to apply diffs in application code will conflict with the harness. Treat every endpoint as an ordinary request and read the body as normal.
Behind an identity gate? The same delta flow applies to endpoints on an identity-gated origin once the client has authenticated; the established identity is reused as the per-client key.
Need a hand with your deployment?Contact support ↗Back to top ↑