Worker RPC Promise Pipelining
A service that exposes objects rather than endpoints, built on Workers RPC, where a call between two Workers is not an HTTP request and therefore does not pay for JSON, a socket, or a round trip. That tax is why service APIs drift coarse: nobody ships getCart then cart.items then item.product across a network, so someone writes getCartWithItemsAndProducts and six months later there are four near-identical aggregate endpoints. The catalog file returns live objects instead, classes extending RpcTarget that the caller receives as stubs backed by state still resident on the service side, including a session that resolves locale and currency once and a cart reachable through it, plus a Map return value that structured clone carries intact and a disposer that runs when the caller releases the stub. It documents the two rules the runtime enforces quietly: only prototype methods are exposed, so a class property arrow function deploys fine and then fails at every call site, and a stub is scoped to the I/O context that created it and cannot be cached across requests. The gateway file is the calling half, where `using` ties stub disposal to the block rather than to the end of the request, and where pipelining is spelled out against the two versions that look identical and cost twice and four times as much, because invoking a method on an unawaited promise sends both hops together and makes the fine-grained API the cheap one.
npx shadcn@latest add https://ui.aryank.space/r/worker-rpc-promise-pipelining.jsonInstalls from ui.aryank.space. To add it by hand, copy the files in Files below, or register the @compronents namespace via the docs.
Over HTTP each dependent call waits for the previous response before it can even start: cart, then items, then product, three serialized round trips with JSON on every wire. Watch the timers stack; this tax is why HTTP service APIs drift into getCartWithItemsAndProducts.
@cloudflare/[email protected]