gRPC Overview

gRPC is Google’s RPC framework, open-sourced in 2015. It uses Protocol Buffers (Protobuf) for the schema and serialization, and HTTP/2 as the transport. Built for service-to-service communication: typed, binary, fast, with first-class streaming.

For comparison with REST/GraphQL/SOAP, see ../00_api_protocols_comparison.md.

The pitch

// user.proto
syntax = "proto3";

service UserService {
  rpc GetUser (GetUserRequest) returns (User);
  rpc ListUsers (ListUsersRequest) returns (ListUsersResponse);
  rpc StreamEvents (EventFilter) returns (stream Event);
}

message GetUserRequest { string id = 1; }
message User { string id = 1; string name = 2; string email = 3; }

From this .proto file you generate:

• Server stubs (Python, Go, Java, …).
• Client stubs (any language).
• Wire format (Protobuf binary).

Calling it from Python:

import grpc
from user_pb2_grpc import UserServiceStub
from user_pb2 import GetUserRequest

channel = grpc.insecure_channel("user-service:50051")
stub = UserServiceStub(channel)

response = stub.GetUser(GetUserRequest(id="42"))
print(response.name)

It looks like a local function call. Underneath: HTTP/2 + binary Protobuf.

Why gRPC

The wins are mostly for service-to-service inside a trusted network: typed contracts, fast wire, code generation, streaming. The losses are at the edge: no native browser support, less human-readable for debugging.

When gRPC fits

• Microservices inside your infrastructure — fast, typed, schema-enforced.
• High-throughput service calls — binary Protobuf vs JSON saves CPU and bandwidth.
• Streaming use cases — log shipping, real-time updates, file transfer; gRPC’s bidirectional streams are first-class.
• Polyglot teams — .proto generates clients for many languages; consistency by construction.
• Mobile clients in your control — Protobuf payloads are smaller than JSON; meaningful on mobile networks.

When gRPC doesn’t fit

• Public-facing browser APIs — browsers don’t speak gRPC natively. gRPC-Web requires a proxy and is more limited.
• Quick experiments / scripts — .proto, codegen, etc. is heavier than curl + JSON.
• External partners who expect REST — REST/OpenAPI is the universal lingua franca.
• Debugging in production — binary payloads aren’t human-readable in logs.

The four method types

service UserService {
  // 1. Unary — request, response (like RPC)
  rpc GetUser (GetUserRequest) returns (User);

  // 2. Server streaming — request, stream of responses
  rpc Search (SearchRequest) returns (stream SearchResult);

  // 3. Client streaming — stream of requests, one response
  rpc UploadFile (stream FileChunk) returns (UploadResult);

  // 4. Bidirectional streaming — both sides stream
  rpc Chat (stream ChatMessage) returns (stream ChatMessage);
}

See 03_service_types_streaming.md.

The architecture

┌─────────────────┐
│ .proto file     │  ← the contract
└─────────────────┘
         │
         ↓ protoc + code generators
┌─────────────────┐     ┌─────────────────┐
│ Python stubs    │     │ Go stubs        │  etc.
└─────────────────┘     └─────────────────┘
         │                       │
         ↓ implement              ↓ implement
┌─────────────────┐     ┌─────────────────┐
│ Python server   │     │ Go client       │
└─────────────────┘     └─────────────────┘
         ↑                       │
         └─── HTTP/2 + Protobuf ─┘

The .proto is the source of truth. Both sides generate code from it; updating the schema means re-running codegen.

Pros and cons

Pros:

• Typed end-to-end (compile-time client/server safety).
• Compact wire format (~3–5× smaller than equivalent JSON).
• Streaming built in.
• HTTP/2 multiplexing — multiple RPCs share one TCP connection.
• Codegen across languages.
• Battle-tested at Google scale.

Cons:

• Not browser-native; needs gRPC-Web for browser clients.
• Binary format is hard to debug without tools.
• Schema evolution rules are easy to get wrong.
• Tooling overhead (protoc, codegen, build).
• Less human-readable than JSON for ad-hoc inspection.

Cross-language stub generation

# Python
python -m grpc_tools.protoc -I. --python_out=. --grpc_python_out=. user.proto
# Generates user_pb2.py and user_pb2_grpc.py

# Go
protoc --go_out=. --go-grpc_out=. user.proto

# Node.js
grpc_tools_node_protoc --js_out=import_style=commonjs --grpc_out=. user.proto

The generated code is what you import in your application — no manual serialization, no manual HTTP code.

File index

Common interview confusions

• “gRPC uses HTTP/1.1.” — always HTTP/2. Required for multiplexing and streaming.
• “gRPC is a replacement for REST.” — for service-to-service yes; for browser-facing APIs no (without gRPC-Web).
• “Protobuf is the same as JSON.” — both are serialization formats but Protobuf is binary, schema-required, and ~5× smaller than equivalent JSON.

Interview angle

• “What is gRPC and how does it work?” — RPC framework using Protobuf for the schema/serialization and HTTP/2 as transport. .proto file defines services and messages; codegen produces server stubs (to implement) and client stubs (to call). Call looks like a local function.
• “Why pick gRPC over REST?” — service-to-service: typed contracts via .proto, ~5× faster wire format (binary Protobuf vs JSON), first-class streaming, HTTP/2 multiplexing. REST when the client is a browser or external partner.
• “What are the four gRPC method types?” — unary (1 req → 1 resp), server streaming (1 req → many resp), client streaming (many req → 1 resp), bidirectional streaming (both stream).
• “Why does gRPC require HTTP/2?” — multiplexes many RPCs on one TCP connection (avoiding head-of-line blocking), supports server-push (used for streaming), header compression (HPACK). Plain HTTP/1.1 can’t do these.
• “Is gRPC the best choice for every API?” — no. Public-facing browser APIs need REST or gRPC-Web (with proxy). External partners expect REST/OpenAPI. Internal service-to-service is where gRPC shines.