When JSON is no longer enough
In modern services, applications no longer talk to each other in a human language: there are thousands of processes, often on different servers, exchanging requests and responses every second. For years the standard was REST with JSON: easy to read, but heavy and slow to process. When traffic grows, that readable format becomes a bottleneck. That is where gRPC comes in, a remote communication framework created by Google that replaces plain text with a binary protocol and is becoming the backbone of communication between microservices.
What gRPC is and where it comes from
gRPC stands for gRPC Remote Procedure Call: the idea of calling a function as if it were in your own program when it actually runs on another machine. It is the evolution of the old RPC (remote procedure calls) that already existed in the 90s, but modernized for the internet era. The “g” in the name refers to the successive versions the project has had throughout its history.
The fundamental difference compared to REST is that the request no longer travels as a text string that anyone can read, but as a compact, optimized sequence of bytes. That is achieved by combining two technologies: HTTP/2 as the transport and Protocol Buffers (protobuf) as the data format.
Protocol Buffers: the schema that defines everything
In REST, JSON is “self-describing”: each request is read in full and you deduce what it contains. In gRPC, by contrast, the data is defined in advance with a schema written in a language called proto. In a .proto file you declare the messages and their fields, like in this example:
syntax = "proto3";
message User {
int32 id = 1;
string name = 2;
string email = 3;
}
service Users {
rpc Get (UserId) returns (User);
}Each field has a number (1, 2, 3…) that is its identifier in the binary. When the data is serialized, that number is the only thing that travels along with the value: the field name no longer takes up space because both sides know the schema. A compiler called protoc automatically generates the code in whatever language you use (Go, Java, Python, C++…), so the same .proto produces clients and servers in all of them. That is the key to interoperability: the schema is the single source of truth.
Why it is faster than JSON
The performance difference is huge for three reasons. First, the size: a protobuf message is typically between 30% and 80% smaller than its JSON equivalent, because it does not repeat the field names or the syntax characters such as quotes or braces. Second, the parsing speed: decoding binary with numbered fields is far cheaper than analyzing text, which reduces CPU and memory usage. And third, the serialization is typed: the receiver already knows that field 1 is an integer, so it does not have to guess or convert.
The encoding uses techniques such as varint, which represents small integers with fewer bytes. A number below 128 takes a single byte even if it is an int32, and space is only reserved as the number grows.
HTTP/2 and bidirectional streaming
gRPC does not travel over HTTP/1.1 but over HTTP/2, the protocol that multiplexes many requests over a single TCP connection. That enables what HTTP/1.1 could not: keeping the connection open and sending and receiving data simultaneously. gRPC defines four types of call:
- Unary: the client sends one request and waits for one response, like in REST.
- Server streaming: the server sends a sequence of responses for a single request (ideal for notifications or real-time updates).
- Client streaming: the client sends many messages and the server answers with one (useful for uploading a batch of data).
- Bidirectional streaming: both sides send messages continuously and simultaneously, like in a chat or a telemetry stream.
This streaming over HTTP/2 is what makes gRPC the preferred choice for microservices architectures, where services must communicate with minimal latency while keeping many simultaneous connections. HTTP/2 also compresses the headers, so not even the request header is sent as plain text.
What you gain and what you lose
The big advantage is efficiency: fewer bytes on the network, less CPU, less memory and faster calls. It also adds powerful features such as multiplexing, request cancellation, deadlines and automatic code generation, which eliminates the errors of writing the client and the server “by hand”. On the other hand, binary traffic is hard to inspect and debug at a glance: you need tools such as grpcurl or the service’s reflection to explore the requests. In addition, browsers do not speak gRPC directly, so to reach a website you use gRPC-Web, an adaptation that does work through the browser.
Where it is used today
gRPC is behind critical infrastructures. Google uses it internally to connect its own services, and it is the mechanism Kubernetes uses for its components to talk to each other. It is also the basis of monitoring systems such as Prometheus, of distributed databases, of streaming services and of almost any platform handling millions of calls per second. When performance is critical and latency matters, plain text is left out and binary takes command.
