Skip to content

PATTERN Cited by 1 source

Global patch constructors for runtime optimization

Pattern

To ship a performance-improving replacement for a standard-library or built-in class to unmodified user code, provide a single-call initialisation function that replaces the global constructors with faster implementations — plus any prototype chain properties (e.g. methods or accessors on types returned by the runtime's built-in network stack) that need to participate in the fast path.

After the patch call, zero changes to consumer code hit the new implementation transparently.

Canonical wiki instance — fast-webstreams

patchGlobalWebStreams() (2026-04-21)

fast-webstreams exports a single function:

import { patchGlobalWebStreams } from 'fast-webstreams';
patchGlobalWebStreams();

The call does two things:

  1. Replaces the global Web-Streams constructors. globalThis.ReadableStream, globalThis.WritableStream, globalThis.TransformStream are swapped to fast-webstreams' implementations.
  2. Patches Response.prototype.body — because fetch response bodies are created inside Node's HTTP layer, not by user code, the only way to intercept them is to patch the accessor that hands out the ReadableStream. The patched accessor returns a fast shell wrapping the native byte stream, allowing subsequent pipeThrough / pipeTo() calls to participate in the fast path (see patterns/record-pipe-links-resolve-at-sink).

After patchGlobalWebStreams(), an unmodified:

const upstream = await fetch('https://api.example.com/data');
const transformed = upstream.body
  .pipeThrough(new TransformStream({ transform(c, ctrl) { ctrl.enqueue(c); } }))
  .pipeThrough(new TransformStream({ transform(c, ctrl) { ctrl.enqueue(c); } }))
  .pipeThrough(new TransformStream({ transform(c, ctrl) { ctrl.enqueue(c); } }));
return new Response(transformed);

hits the fast pipeline path — 3.2× faster than native, per the 2026-04-21 benchmark. (sources/2026-04-21-vercel-we-ralph-wiggumed-webstreams-to-make-them-10x-faster)

Why not just rename the classes?

Consumer code imports ReadableStream / WritableStream / TransformStream as globals or from runtime modules (node:stream/web). Libraries consumed by the app also use these globals. Renaming means changing every import in every dependency — not feasible.

Patching globals means the swap happens once at process start and applies to every downstream consumer, transitively.

Why Response.prototype.body needs explicit patching

Constructors alone don't cover streams the user didn't construct. fetch() is the major case — response bodies come from Node's HTTP layer, which instantiates native ReadableStream directly, bypassing the patched constructor. Without Response.prototype.body patching, fetch() chains stay on the slow path.

The pattern generalises: any type the runtime itself constructs on your behalf needs explicit prototype-chain patching to fully convert.

Forces

  • Drop-in upgrade. Patch once, zero consumer code changes, whole process converts.
  • Native objects as entry points. fetch / crypto / other built-in-constructed streams need prototype patching because the constructor swap doesn't catch them.
  • Process-global scope. The patch applies to the whole process; fine-grained per-request opt-in requires a different approach.

Counter-indications

  • Test isolation. Global patching can leak between tests; needs careful unpatch in test teardown.
  • Library authors checking instanceof against the original. If any library does instanceof globalThis.ReadableStream and the patched class is a different constructor, comparisons may fail. This is why fast-webstreams implementations must preserve instanceof compatibility — typically by making the patched class subclass or mimic the original.
  • Fallback paths still needed. Even with the global patched, unusual stream shapes may hit spec edges the patched implementation hasn't covered. WPT conformance is how fast-webstreams keeps this surface small.

Rollout discipline

Because the patch is process-global and affects every request, Vercel's rollout is explicitly incremental:

"At Vercel, we are looking at rolling this out across our fleet. We will do so carefully and incrementally. Streaming primitives sit at the foundation of request handling, response rendering, and compression. We are starting with the patterns where the gap is largest: React Server Component streaming, response body forwarding, and multi-transform chains. We will measure in production before expanding further."

Staged rollout via feature flags / per-project opt-in / per-workload evaluation — the same shape as any runtime-level rollout.

Distinct from

  • Runtime flag or CLI option (e.g. --experimental-fast-webstreams) — requires Node- level integration; patchGlobalWebStreams() is userland and needs no Node support.
  • Vendoring the fast implementation into user code under a different name — doesn't patch Response.prototype.body, doesn't convert the whole process, requires code changes.
  • Bun's non-standard "Direct Streams" API — different API, requires consumer code to target the non-standard shape. fast-webstreams' pattern keeps the standard API and replaces the implementation underneath.

Sibling / precursor examples

  • Babel / core-js polyfills — same structural pattern, opposite motivation: provide missing implementations in older runtimes. Global-patch pattern is identical; the motivation here is replace slow existing implementations rather than provide missing implementations.
  • async-hooks contextual storage — installs global hooks into Node's async machinery; similar process-global reach.
  • OpenTelemetry instrumentation — patches http.request et al at module level to add tracing.

The pattern is well-established; what's notable in the 2026-04-21 case is using it specifically to roll out a faster implementation of a W3C standard without needing runtime cooperation.

Seen in

Last updated · 476 distilled / 1,218 read