gRPC

Updated September 30, 20262 min read

In short

gRPC is an open-source framework for calling functions on a remote server as if they were local, using Protocol Buffers and HTTP/2 for fast, typed messages.

What is gRPC?

gRPC is a remote procedure call (RPC) framework: it lets a program call a function that actually runs on another machine, while the network details are handled for you. It was developed at Google, released as open source in 2015, and is now a Cloud Native Computing Foundation (CNCF) project. It is used mostly for communication between backend services.

You start by describing your service in a .proto file using Protocol Buffers, a compact binary data format with a strict schema. A code generator then creates client and server code in languages such as Go, Java, Python, C#, and TypeScript, so calling a remote method feels like calling a local function with typed arguments. gRPC runs over HTTP/2, which allows many calls to share one connection and supports streaming data in either or both directions.

If a REST API is like exchanging flexible, human-readable letters, gRPC is like a phone call that follows a script both sides agreed on in advance, so each knows exactly what every message will contain. That strictness and the binary encoding make gRPC fast and compact, which is why it is popular in microservices, mobile backends, and systems with very high request volumes.

gRPC is often compared with REST. REST exposes resources at URLs, usually sends JSON, and works directly from browsers, while gRPC exposes methods, sends binary Protocol Buffer messages, and needs the gRPC-Web variant or a proxy to be called from a browser. Many teams use gRPC internally between services and offer a REST or GraphQL API to public and browser clients.

Key takeaways

gRPC lets clients call methods on a remote server like local functions.
Services and messages are defined in .proto files using Protocol Buffers.
Client and server code is generated automatically for many languages.
It runs over HTTP/2 and supports streaming in both directions.
Browsers need gRPC-Web or a proxy, so gRPC is most common between backend services.

Example

Defining a gRPC service in a .proto fileprotobuf

// user.proto: the contract shared by client and server
syntax = "proto3";

package users.v1;

service UserService {
  // Unary call: one request, one response
  rpc GetUser (GetUserRequest) returns (User);
  // Server streaming: one request, a stream of responses
  rpc ListUsers (ListUsersRequest) returns (stream User);
}

message GetUserRequest { int64 id = 1; }
message ListUsersRequest { int32 page_size = 1; }
message User { int64 id = 1; string name = 2; string email = 3; }

Readers ask

What is the difference between gRPC and REST?

REST uses URLs for resources, standard HTTP methods, and usually JSON, while gRPC defines typed methods in a .proto file and sends compact binary messages over HTTP/2. gRPC is typically faster and stricter; REST is simpler to debug and works natively in browsers.

Can I use gRPC from a web browser?

Not directly, because browsers don't expose the low-level HTTP/2 features gRPC relies on. Web apps use gRPC-Web, usually through a proxy that translates requests, or call a separate REST or GraphQL API instead.

What are Protocol Buffers?

Protocol Buffers, or protobuf, is a language-neutral format created at Google for defining structured data and serializing it into small binary messages. gRPC uses it by default to describe services and to encode every request and response.

Often compared

REST vs gRPCREST exposes resources over HTTP, usually as JSON, while gRPC calls typed remote functions with binary messages over HTTP/2: faster, but harder from browsers.