PATTERN Cited by 1 source

gRPC-web transparent translation

An edge-proxy pattern where the reverse proxy automatically converts between gRPC (HTTP/2 framed, requires stream-level control) and gRPC-web (HTTP/1.1-compatible encoding) at the network boundary, allowing compute that can only speak HTTP/1.1 or web-platform APIs to serve and call gRPC services without clients or backends needing modification.

Problem

gRPC depends on HTTP/2 frame-level control: stream IDs for multiplexing, per-stream flow control, cancellation semantics, and trailers. Web platform APIs (fetch(), ReadableStream) don't expose this control — there is no raw TCP Socket API in browsers. Serverless runtimes (Workers, Lambda, etc.) similarly don't expose HTTP/2 frame-level primitives to user code.

Solution

The edge proxy performs bidirectional protocol translation:

• Inbound: gRPC (HTTP/2) → gRPC-web (HTTP/1.1-compatible) before reaching the Worker
• Outbound: gRPC-web (HTTP/1.1-compatible) → gRPC (HTTP/2) before reaching external servers

Worker code uses @connectrpc/connect (gRPC-web library) — the standard gRPC client/server interface — while the outside world sees standard gRPC. No changes required on either side.

Trade-offs

• Supports unary + server-streaming directly from Workers (no container needed)
• Client-streaming and bidirectional-streaming require raw TCP — must use the Container path with socket passthrough
• Adds a protocol translation hop at the edge (minimal latency given co-location)
• Protobuf definition required for code generation

Seen in

• sources/2026-08-03-cloudflare-workers-and-containers-now-support-inbound-tcp-connections-and-grpc — Cloudflare has performed gRPC↔gRPC-web conversion since 2020 in its reverse proxy; extended in 2026 to let Workers serve and call gRPC (private beta)