The Point

gRPC is an RPC framework developed by Google. It uses HTTP/2 for transport and Protobuf for serialization, making it faster and more structured than traditional REST/HTTP+JSON – but less readable, so it is mainly used for internal microservice communication.

Explanation

Traditional HTTP (REST + JSON)

Client → POST /users HTTP/1.1
         Content-Type: application/json
         {"name": "Alice", "age": 30}

Server → 200 OK
         {"id": 1, "name": "Alice"}

• Operations are defined by URL + HTTP method
• Data format is JSON (human-readable text)
• Based on HTTP/1.1 (each request uses an independent connection)

How gRPC does it

Client → calls UserService.CreateUser(CreateUserRequest)
Server → returns CreateUserResponse

• Services and messages are defined in .proto files; calling them feels like calling a local function
• Data format is Protobuf (binary, not directly readable)
• Based on HTTP/2 (multiplexing – a single connection handles multiple requests)

Core differences

Knowledge Sugar

What is HTTP/2 multiplexing?

In HTTP/1.1, each request must wait for the previous response before sending the next one (or open a new connection). HTTP/2 can handle multiple request/response pairs in parallel over a single connection, significantly reducing latency.

Streaming

gRPC supports four communication modes, which are hard to do with REST:

Unary:              one request → one response (most common)
Server streaming:   one request → multiple responses (e.g. real-time push)
Client streaming:   multiple requests → one response (e.g. uploading chunked data)
Bidirectional:      multiple requests ↔ multiple responses (e.g. real-time chat)

Relation to Protobuf gRPC’s data format is Protobuf – see the earlier post on Protobuf Reserved Fields & API Versioning for more context.