resonate-state-bus-pattern-typescript

Resonate State Bus Pattern (TypeScript)

Overview

A long-running Resonate workflow often needs to surface progress to a live UI. If the worker is short-lived (Cloud Function, Lambda) or scales to zero, holding an SSE or WebSocket connection for the workflow's lifetime isn't an option — the connection outlives the worker process.

The state bus pattern decouples the two sides:

1. The workflow writes its current state to an external realtime bus via ctx.run.
2. The browser (or any subscriber) subscribes to that bus directly.

The worker stays stateless, progress becomes durable (ctx.run guarantees it), and the UI becomes a pure read view — the workflow can run with or without anyone watching.

Mental Model

Worker (short-lived)             Bus                    Browser (long-lived)
   │                              │                              │
   ├─ ctx.run(writeState, s1) ──▶ │                              │
   │                              ├─ notify subscribers ───────▶ render(s1)
   │  [worker returns, scales to  │                              │
   │   zero — bus persists state] │                              │
   │                              │                              │
   ├─ ctx.run(writeState, s2) ──▶ │                              │
   │                              ├─ notify subscribers ───────▶ render(s2)

The workflow never talks to a client. The client never talks to the workflow. Both sides talk to the bus.

When to use this pattern

• Your worker is serverless (Cloud Functions, Lambda, Edge Functions) and can't hold a persistent connection.
• The workflow must run whether or not anyone is subscribed (e.g. a shared game, a batch job whose output is watched by an ops dashboard).
• Multiple clients need the same live view of the same workflow.
• You want the workflow's progress to survive worker restarts and cold starts with no reconnection logic in the UI.

When NOT to use this pattern

• The worker already runs in the browser (see example-browser-worker-ts) — then the client is the worker, and in-tab state works.
• The workflow is short enough to fit inside a single request/response — just return the result.
• The consumer is another service that can long-poll the Resonate server directly.