Browsers need a proxy for native gRPC; this guide shows Envoy, gRPC-Web codegen, binary mode, and verification for production RPCs. Read now.
Why browsers need a proxy for gRPC
Native gRPC depends on HTTP/2 features and framing that ordinary browser APIs do not expose end to end. JavaScript running in a page cannot open a raw gRPC channel the way a backend service can, so a translation layer sits between the browser and your gRPC services. That layer accepts traffic the browser can send, rewrites it into standard gRPC on the backend side, and returns responses in a form the client library understands.
Without that proxy, you either abandon gRPC at the edge or invent an ad hoc REST wrapper that duplicates schemas and error models. gRPC-Web exists to keep one contract—your protobuf services—while making the browser path explicit and predictable rather than hidden behind one-off HTTP handlers.
Envoy as the edge translator
Envoy is a common choice for that translation because it already understands HTTP/2, upstream clusters, and gRPC-Web filters. You terminate browser traffic at Envoy, enable the gRPC-Web filter on the relevant route, and point the cluster at your real gRPC services. Timeouts, retries, and TLS stay in one place instead of being reimplemented in application code for every language stack.
Keep the configuration boring and inspectable: separate listener and cluster definitions, clear host matching for your API domain, and health checks on upstreams so a dead backend fails loudly. Treat the proxy as part of the production path—version its config, deploy it with the same care as the services behind it, and log status codes that distinguish filter failures from application errors.
Codegen and binary mode
gRPC-Web codegen turns your .proto definitions into typed client stubs for the browser. You generate once from the same schemas your servers use, then call methods that look like ordinary RPC helpers instead of hand-rolled fetch payloads. That keeps request and response shapes aligned across stack boundaries and reduces silent field drift when messages evolve.
Prefer binary mode over text-encoded modes when you care about payload size and fidelity. Binary framing carries protobuf wire format more directly, which cuts encoding overhead and preserves types that text paths can blur. Wire the client for binary, confirm Envoy and your services agree on content types, and fail the build if generated stubs fall out of sync with the protos deployed on the server.
- Regenerate stubs whenever protos change; never hand-edit generated clients.
- Pin the same package names and service paths on both sides of the proxy.
- Enable compression only after you measure that it helps your message sizes.
Verification before you call it production
Ship a short verification checklist with every environment promotion. Call a known unary method through the full path—browser client, proxy, service—and assert status, headers, and body shape. Exercise streaming only if you actually use it; unary success does not prove stream framing works. Confirm CORS, credentials, and deadline behavior under real browser constraints, not only with backend test clients.
Log correlation IDs from the browser through Envoy into service logs so a failed RPC is traceable in one query. Add a canary or smoke test that runs after deploy and alerts when the proxy filter or upstream cluster misroutes. High-performance browser RPC is less about clever clients and more about a correct proxy, shared schemas, binary encoding, and checks that catch breaks before users do.