gRPC: Google Remote Procedure Call

What is gRPC?

gRPC is a high-performance, open-source remote procedure call (RPC) framework originally created by Google in 2015. Google had been using an internal RPC system called Stubby for over a decade to connect its massive network of microservices, handling billions of requests per second across its data centers. When the team decided to build a next-generation version and open-source it, the result was gRPC. It was donated to the Cloud Native Computing Foundation (CNCF) in 2017 and reached graduated status in 2019, putting it alongside projects like Kubernetes and Prometheus.

At its core, gRPC uses HTTP/2 as its transport protocol and Protocol Buffers (protobuf) as its default serialization format. This combination gives it significant advantages over traditional REST+JSON APIs. HTTP/2 provides multiplexed streams over a single TCP connection, header compression via HPACK, and native support for bidirectional communication. Protocol Buffers serialize data into a compact binary format that is typically 3 to 10 times smaller than equivalent JSON and significantly faster to parse. Together, these technologies make gRPC well suited for latency-sensitive, high-throughput communication between services.

gRPC supports client libraries in over 11 languages, including Go, Java, Python, C++, C#, Node.js, Ruby, Dart, Kotlin, Swift, and PHP. This polyglot support means a Go service can call a Java service with strongly-typed interfaces and no manual serialization code. Major companies rely on gRPC in production. Netflix uses it for inter-service communication across its microservice fleet. Dropbox migrated from a custom RPC framework to gRPC. Square uses it for mobile-to-backend communication. Lyft, CoreOS (etcd), CockroachDB, and Cisco all use gRPC as a core part of their infrastructure. The reason is straightforward: REST with JSON is too slow and too loosely typed for internal microservice communication at scale.

How gRPC Works: Service Definitions and Protobuf

Every gRPC service starts with a .proto file. This file defines the service interface, the methods it exposes, and the message types used for requests and responses. The .proto file acts as a contract between client and server, and both sides generate code from it. This is fundamentally different from REST APIs, where the contract is typically a loosely enforced OpenAPI specification or just documentation.

Here is a simple .proto file for a greeting service:

syntax = "proto3";

package helloworld;

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
  rpc SayHelloStream (HelloRequest) returns (stream HelloReply);
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

The protoc compiler takes this file and generates client stubs and server interfaces in your target language. In Go, you get a typed client with a SayHello() method that accepts a HelloRequest struct and returns a HelloReply struct. In Java, you get equivalent classes. There is no manual JSON parsing, no string-based URL routing, and no ambiguity about what fields exist or what types they are.

Protocol Buffers use a binary encoding that is both smaller and faster than JSON. Each field is identified by its field number (the = 1 in the definition) rather than its name, which saves space on the wire. A protobuf message containing a short string might be 10 bytes, while the equivalent JSON could be 40 bytes or more. Protobuf schemas also support forward and backward compatibility. You can add new fields to a message without breaking existing clients, and old clients will simply ignore fields they do not recognize. This makes schema evolution much safer than modifying JSON response structures.

The Four gRPC Call Types

gRPC supports four distinct call types, each suited to different communication patterns. This is one of its biggest advantages over REST, which only supports the request-response pattern natively.

Unary RPC is the simplest type and works like a traditional function call. The client sends a single request and receives a single response. This is equivalent to a standard REST API call. A typical example is GetUser(userId), where the client requests a user record and the server returns it. Most gRPC services use unary calls for the majority of their methods.

Server Streaming RPC allows the server to send a stream of messages in response to a single client request. The client sends one request and then reads messages from the stream until there are no more. A practical example is a stock price feed: the client subscribes to a ticker symbol, and the server streams price updates as they happen. This is also useful for paginated data where the server can push results as they become available rather than assembling an entire response first.

Client Streaming RPC is the inverse. The client sends a stream of messages to the server and receives a single response when the stream completes. File uploads are the classic use case. The client streams file chunks to the server, and when the upload finishes, the server responds with a confirmation and metadata. Sensor data ingestion is another common application, where a device streams readings and the server responds with a summary after processing them.

Bidirectional Streaming RPC allows both the client and server to send streams of messages independently. Both streams operate concurrently, and neither side needs to wait for the other to finish. Chat applications are a natural fit: both the client and server send messages whenever they have something to say. Collaborative editing, real-time gaming, and interactive voice processing all benefit from this pattern. The two streams are independent, so the server can respond to messages as they arrive or buffer them and respond in batches.

gRPC Message Framing over HTTP/2

gRPC is built directly on HTTP/2, and it takes full advantage of the protocol's features. HTTP/2 multiplexes multiple streams over a single TCP connection, which means a client can have dozens of concurrent gRPC calls in flight without opening additional connections. HPACK header compression reduces the overhead of repeated headers across requests. Binary framing eliminates the text-based parsing overhead of HTTP/1.1.

Each gRPC call maps to a single HTTP/2 stream. The call begins with a HEADERS frame containing pseudo-headers like :method POST, :path /package.Service/Method, and content-type application/grpc. The te: trailers header is required because gRPC uses HTTP/2 trailers to send the final status code after the response body.

The message payload is sent in DATA frames using a simple length-prefixed format. Each message is preceded by 5 bytes: a 1-byte compressed flag (0x00 for uncompressed, 0x01 for compressed) followed by a 4-byte big-endian message length. The serialized protobuf message follows immediately after. This framing allows the receiver to know exactly how many bytes to read for each message, which is critical for streaming calls where multiple messages flow through the same HTTP/2 stream.

When the call completes, the server sends a TRAILERS frame containing the grpc-status code (0 for success) and an optional grpc-message field with a human-readable description. This separation of status from the response body is a key design decision. It means the server can start streaming response messages before it knows the final outcome, then report success or failure in the trailers.

gRPC Request and Response Examples

Below is a breakdown of what a unary gRPC call looks like on the wire. The client calls SayHello on the helloworld.Greeterservice with a name field set to "World". The examples show the HTTP/2 frames and the length-prefixed gRPC message format.

gRPC Request (Client to Server)

gRPC Response (Server to Client)

gRPC vs REST Comparison

gRPC and REST are both popular approaches for building APIs, but they make fundamentally different trade-offs. REST is the standard for public-facing web APIs and browser-based applications. gRPC excels at internal service-to-service communication where performance, type safety, and streaming matter.

In benchmarks, gRPC typically processes requests 5 to 10 times faster than REST+JSON for the same payload, with message sizes 3 to 10 times smaller. The performance gap widens with larger payloads and higher request volumes. However, REST remains the better choice for browser-facing APIs, third-party integrations, and any situation where human readability and simplicity are priorities.

Key Features of gRPC

• Multiplexing: HTTP/2 allows multiple gRPC calls to share a single TCP connection. There is no head-of-line blocking at the application layer, so a slow response on one call does not block other calls on the same connection.
• Bidirectional streaming: both client and server can send messages independently on the same call, enabling real-time communication patterns that are difficult to implement with REST.
• Code generation: the protoc compiler generates strongly-typed client stubs and server interfaces from .proto files. This eliminates boilerplate serialization code, reduces bugs from type mismatches, and provides compile-time safety.
• Deadlines and timeouts: gRPC has built-in deadline propagation. A client sets a deadline, and it automatically propagates through the entire call chain. If service A calls service B which calls service C, and the original deadline expires, all three services know to stop processing.
• Flow control: HTTP/2 flow control prevents a fast sender from overwhelming a slow receiver. This is managed per-stream and per-connection, giving fine-grained control over buffer sizes.
• Interceptors and middleware: gRPC provides a clean interceptor API (similar to HTTP middleware) for adding cross-cutting concerns like logging, authentication, metrics, and tracing to all calls without modifying service logic.
• Health checking: gRPC defines a standard health checking protocol that load balancers and orchestration systems like Kubernetes use to determine if a service is ready to receive traffic.
• Load balancing: gRPC supports both proxy-based load balancing (like Envoy or NGINX) and client-side load balancing, where the client discovers service instances and distributes calls across them directly.

Common Use Cases

• Microservice-to-microservice communication: this is the primary use case for gRPC. Services within a backend system communicate through strongly-typed, high-performance RPC calls instead of REST endpoints. Companies like Netflix and Lyft use gRPC to connect hundreds of internal services.
• Mobile backend APIs:gRPC's compact binary format reduces bandwidth usage on cellular networks. Square uses gRPC for its mobile payment applications, where smaller payloads translate directly to faster transactions and lower data costs for users.
• Real-time streaming: server streaming and bidirectional streaming make gRPC well suited for live data feeds, event-driven architectures, and real-time monitoring dashboards. Financial trading platforms use server streaming for market data delivery.
• Polyglot service communication:when services are written in different languages, gRPC's code generation eliminates the need for manual serialization. A Python ML model serving predictions can be called from a Go API gateway with full type safety on both sides.
• Internal APIs at scale: organizations with large service meshes adopt gRPC because of its strict API contracts, backward-compatible schema evolution, and performance characteristics. The overhead savings compound as request volume grows into the millions per second.

Frequently Asked Questions About gRPC

What does gRPC stand for?

The "g" in gRPC stands for something different in each release. In 1.0 it stood for "gRPC" (recursive acronym). In later releases it has stood for "good," "green," "glamorous," and other words. The official interpretation is simply "gRPC Remote Procedure Call." The "RPC" part stands for Remote Procedure Call, which describes its core function: calling a method on a remote server as if it were a local function call.

Is gRPC faster than REST?

Yes, in most benchmarks gRPC is significantly faster than REST+JSON. The performance advantage comes from three factors. Protocol Buffers produce smaller payloads than JSON (typically 3 to 10 times smaller). Binary serialization and deserialization is faster than JSON text parsing. And HTTP/2 multiplexing allows many concurrent calls over a single connection, reducing connection overhead. In real-world tests, gRPC often achieves 5 to 10 times higher throughput than equivalent REST APIs for the same workload.

Can gRPC work in web browsers?

Not directly. Browsers do not expose the low-level HTTP/2 framing controls that gRPC requires. The solution is gRPC-Web, a companion protocol that adapts gRPC for browser clients. gRPC-Web uses a proxy (like Envoy) that translates between the browser-compatible format and standard gRPC. It supports unary and server streaming calls but does not support client streaming or bidirectional streaming. Projects like Connect (from Buf) also provide browser-compatible gRPC alternatives that work over HTTP/1.1.

What is Protocol Buffers (protobuf)?

Protocol Buffers is a language-neutral, platform-neutral data serialization format developed by Google. You define your data structures in .proto files, then use the protoc compiler to generate code for reading and writing those structures in your target language. Protobuf encodes data in a compact binary format, making it faster and smaller than JSON or XML. While gRPC uses protobuf by default, gRPC can technically use other serialization formats like JSON or FlatBuffers.

Does gRPC support authentication?

Yes. gRPC has built-in support for TLS encryption and several authentication mechanisms. It supports SSL/TLS for transport security, token-based authentication (commonly JWT or OAuth2 tokens passed as call metadata), and Google token-based authentication for GCP services. The interceptor API makes it straightforward to add custom authentication logic. In Kubernetes environments, service mesh solutions like Istio provide mutual TLS (mTLS) authentication between gRPC services automatically.

When should I use REST instead of gRPC?

REST is the better choice when you need browser-native support without a proxy, when your API is public-facing and consumed by third-party developers who expect JSON, when human readability of requests and responses is important for debugging, or when your team is more familiar with REST tooling. REST is also simpler to set up for small projects and CRUD-style APIs where the overhead of protobuf schema management is not justified. If your API will primarily be called from web browsers or curl commands, REST is typically the more practical option.

Related Protocols

• HTTP: the foundational web protocol, with HTTP/2 serving as the transport layer for gRPC
• HTTPS: the encrypted version of HTTP, used by gRPC in production deployments with TLS on port 443
• MQTT: a lightweight publish-subscribe protocol for IoT, offering a different approach to real-time messaging than gRPC streaming
• RTP: the Real-time Transport Protocol used for audio and video delivery, another protocol designed for low-latency streaming