Skip to main content
QuantLab Logo
Glossary · APIs

What is gRPC?

gRPC is a high-performance remote procedure call framework: you define your service and its messages in a Protocol Buffers file, a code generator produces typed clients and servers in your language, and the calls travel as compact binary payloads over HTTP/2 — making it the default choice for fast, strongly typed communication between microservices.

RPC, briefly

Remote procedure call is an old idea: make calling a function on another machine look like calling a local function. gRPC is Google's modern take, open-sourced in 2015 and now a Cloud Native Computing Foundation project. Instead of thinking in URLs and verbs the way a REST API does, you think in methods and messages — GetUser(UserRequest) returns (User) — and the framework handles serialization, transport, and connection management.

Protocol Buffers and codegen

The contract lives in a .proto file: language-neutral definitions of your messages and service methods. A compiler reads it and generates strongly typed client and server stubs in Go, Java, Python, TypeScript, and more. That codegen is the headline productivity win — change a field in the schema, regenerate, and every consumer gets compile-time errors instead of silent runtime surprises. The wire format is compact binary, not JSON, so payloads are smaller and parsing is cheap.

HTTP/2 and streaming

gRPC rides on HTTP/2, which gives it multiplexing — many concurrent calls over one connection without head-of-line blocking. It also unlocks four call styles: unary (one request, one response), server streaming, client streaming, and bidirectional streaming. That streaming support is why teams pick gRPC for things like live telemetry, chat backplanes, and progress feeds where WebSockets would otherwise be the tool of choice.

The browser problem

Here is the catch that surprises people: browsers cannot speak raw gRPC, because JavaScript has no access to the underlying HTTP/2 frames. The workaround is gRPC-Web, a variant that runs through a proxy (often an API gateway or Envoy). For this reason, many architectures use gRPC for internal service-to-service traffic and expose a REST or GraphQL edge to the public web. gRPC is a backend-to-backend specialist first.

When to reach for it

gRPC pays off when you have many services talking to each other at high volume, want a single source of truth for the contract, and care about latency and payload size. It is heavier to debug than JSON — you cannot just curl a binary endpoint and read the output — and it adds operational pieces like proxies for the browser. For a small system with a few public endpoints, REST is usually the simpler, cheaper call. For a sprawling microservices backend, gRPC earns its keep.

At QUANT LAB

On internal platforms we use gRPC where it fits: a shared .proto registry, generated clients, and a thin REST or GraphQL edge for browsers. Our API development engagements include the unglamorous parts — versioning the protobuf schema without breaking consumers, wiring deadlines and retries, and putting authentication on every method. We do not bolt gRPC onto a system that would be perfectly happy with a REST API; the right protocol is the one that matches the traffic.

Standing up a gRPC backend?

We design protobuf contracts, set up codegen and streaming, and bridge gRPC to the browser cleanly. Book a 30-minute call.

API development