gRPC-Web brings gRPC, Google’s high-performance remote procedure call framework, to web browsers. The repository describes it simply as “a JavaScript implementation of gRPC for browser clients.” It lets front-end code call gRPC services using the same Protocol Buffers message definitions and generated client stubs that back-end services use, so a browser application can invoke strongly typed RPCs instead of hand-rolling REST calls and JSON parsing.
The reason gRPC-Web exists is a hard constraint of the browser platform. Standard gRPC runs over HTTP/2 and relies on low-level control of HTTP/2 frames and trailers that browser fetch and XMLHttpRequest APIs do not expose. A browser simply cannot originate the raw HTTP/2 gRPC wire protocol. gRPC-Web defines an alternative wire format that a browser can produce and consume, and it depends on a proxy to bridge the two worlds.
That proxy is the heart of the design. As the project explains, “gRPC-web clients connect to gRPC services via a special proxy; by default, gRPC-web uses Envoy.” The browser speaks the gRPC-Web protocol to the proxy over ordinary HTTP, and the proxy translates those requests into native gRPC calls to the backend, then translates the responses back. This keeps the browser client thin while letting the server side remain unmodified gRPC. The format supports unary request-response calls and server-side streaming, the latter available when using the grpcwebtext mode.
For developers, the workflow mirrors ordinary gRPC. A service is described in a .proto file, the protoc compiler with the gRPC-Web plugin generates browser client code, and the application imports those generated stubs to make calls. The generated code handles serializing Protocol Buffers messages into the gRPC-Web framing and parsing the responses, hiding the proxy translation behind a clean method-call interface that feels like calling a local object.
gRPC-Web matters because it extended the reach of gRPC from server-to-server communication, where it was already popular for its efficiency and contract-first typing, into the browser tier of an application. Teams already invested in gRPC and Protocol Buffers could reuse the same service definitions end to end rather than maintaining a separate REST or GraphQL facade just for web clients. The trade-off is the required proxy hop, a direct consequence of browsers being unable to speak native gRPC over HTTP/2.