What Is gRPC?
How Remote Procedure Calls Work
What is gRPC? gRPC is an open-source remote procedure call (RPC) framework, originally developed at Google, that lets a program run a function on another machine as if it were local. It is most often used for communication between backend services rather than between a browser and a server.
With a typical REST API, the caller builds an HTTP request for a URL and interprets the response itself. With RPC, the caller invokes a named method, such as GetInvoice, and the framework turns that call into network traffic and back again.
gRPC adds specific choices to the basic idea. Services, their methods and the messages they accept and return are described in a shared contract file written in Protocol Buffers, usually called a .proto file. Tools read that file and generate client and server code for many programming languages, so both sides agree on the data shape.
Protocol Buffers, often shortened to protobuf, is a compact binary format for structured data. Because messages are binary rather than text, they are often smaller and quicker to parse than equivalent JSON, although the gain depends on the data. gRPC runs over HTTP/2, which lets many requests and responses share one connection at the same time.
Streaming and Call Types in gRPC
gRPC supports four call patterns. A unary call sends one request and gets one response, much like a typical REST call. Server streaming sends one request and receives a sequence of messages, such as a live feed of log lines. Client streaming sends a sequence of messages and receives one reply at the end. Bidirectional streaming lets both sides send messages independently over the same connection.
Field numbers in a .proto file identify each piece of data on the wire. Adding a new field is generally safe, because older clients ignore fields they do not know. Changing or reusing a field number, however, can silently corrupt data for clients that still use the old contract.
Where gRPC Fits Compared With REST
gRPC is a common choice for internal service-to-service traffic, where one team controls both ends of the connection and can generate code from the same contract. A hosting platform, for example, might use gRPC between its own internal services while offering customers a public REST API.
REST remains the usual choice for public APIs. Any HTTP client can call a REST endpoint with a URL and a text payload. gRPC needs generated code or a library in each language, and browsers cannot call gRPC services directly. They typically use a variant called gRPC-Web, which needs a proxy to translate between the two protocols.
For a different style of real-time traffic, where a connection stays open for messages in both directions, see how WebSockets work. For the architectural style most public APIs use, see what a REST API is.
Frequently asked questions
Is gRPC faster than REST?
Not always. gRPC often uses less bandwidth and processing for large volumes of structured data, because Protocol Buffers are binary and connections are reused. For a single small request, the difference is usually minor, and network distance, database queries and payload design matter more. Measure with your own workload before choosing.
Can a browser call a gRPC service directly?
Not in the standard way. Browsers do not give JavaScript the low-level HTTP/2 control that gRPC expects, so browser applications usually use gRPC-Web. A proxy then converts those requests into regular gRPC for the backend service.