What Is gRPC? – Definition and How It Works

Informational P2 what is grpc

Learn what gRPC is, how protocol buffers and HTTP/2 combine, what the four call types are, and where it fits against REST.

gRPC is a remote procedure call framework using protocol buffers for serialisation and HTTP/2 for transport. Services are defined in a schema file from which client and server code is generated.

1. The Schema Comes First

service ProductService {
  rpc GetProduct (GetProductRequest) returns (Product);
  rpc ListProducts (ListProductsRequest) returns (stream Product);
}

message Product {
  string id = 1;
  string name = 2;
  double price = 3;
}

The definition generates client and server code in many languages, so the contract is enforced by the compiler rather than by documentation and hope.

2. Why Protocol Buffers

Binary and compact — substantially smaller than JSON.
Typed, with the schema shared by both sides.
Fast to serialise and parse.
Evolvable, through numbered fields that allow safe addition.

Field numbers are the mechanism for compatibility: adding a new numbered field does not break old readers, which is what makes rolling deployments practical.

3. Why HTTP/2

Multiplexing lets many calls share one connection without head-of-line blocking, and long-lived streams are natural rather than bolted on. That combination is what makes the streaming call types possible.

4. The Four Call Types

Type	Shape	Example
Unary	One request, one response	Fetch a product
Server streaming	One request, many responses	Stream a large result set
Client streaming	Many requests, one response	Upload in chunks
Bidirectional	Both stream independently	Live interaction

Streaming is a first-class concept rather than a workaround, which is a genuine difference from request-response APIs.

5. Where It Fits

Service-to-service communication inside a system.
Polyglot environments, where generated clients remove per-language integration work.
High-throughput paths, where payload size and parsing cost matter.
Streaming workloads, where partial results should flow as produced.

6. Where REST Fits Better

Public APIs, where a browser-friendly, human-inspectable interface matters.
Direct browser calls, which need a proxy layer for gRPC.
Simple resource access, where a schema and code generation are overhead.
HTTP caching, which REST uses naturally and gRPC does not.

Debuggability is a real consideration too: a REST call can be reproduced with a command-line tool and read by eye; a binary gRPC call cannot.

7. Practical Notes

Deadlines are first-class and should be set on every call.
Errors use a defined status set, richer than HTTP status codes.
Reflection allows tools to discover services without the schema file.
Browser support requires a translating proxy.

8. Summary

gRPC combines schema-first protocol buffers with HTTP/2 transport to give typed, compact, code-generated remote calls in four shapes including streaming.

It suits internal, polyglot, high-throughput, and streaming communication. REST remains preferable for public, browser-facing, cacheable interfaces where inspectability matters more than efficiency.