A Faster, Strongly Typed Alternative to REST
gRPC is a remote procedure call framework built by Google on top of HTTP/2 and Protocol Buffers, designed specifically for high-performance service-to-service communication inside a microservices architecture. Instead of hand-writing JSON payloads and guessing field names, you define a .proto file describing your service's methods and message shapes, and gRPC generates strongly typed client and server code in whatever languages you need — Go, Java, Python, and more — that all speak the same binary wire format. This eliminates an entire category of bugs caused by mismatched field names or types between REST clients and servers.
Cricket analogy: A .proto file acting as the single source of truth for message shapes is like the official MCC Laws of Cricket being the one rulebook every team, umpire, and broadcaster references, eliminating ambiguity about what a 'wide' means.
Defining Services with Protocol Buffers
A .proto file declares message types with numbered fields and RPC methods grouped into a service, and the protoc compiler turns that definition into idiomatic code for each target language. Numbered fields (like customer_id = 1) rather than field names on the wire is what makes Protocol Buffers so compact and fast to parse compared to JSON's verbose text. Because the schema is explicit and versioned in source control, both client and server teams compile against the exact same contract, catching mismatches at compile time instead of discovering them at runtime in production.
Cricket analogy: Numbered fields in a proto message are like a scorecard using fixed column positions for runs, balls, and fours rather than free-text notes, making parsing fast and unambiguous.
Streaming and Performance
Beyond simple unary request-response, gRPC natively supports four call types: unary, server streaming (one request, many responses), client streaming (many requests, one response), and bidirectional streaming, all multiplexed efficiently over a single HTTP/2 connection. This makes gRPC a strong fit for scenarios like a live pricing feed streaming updates to a client, or a client uploading a large batch of records incrementally. Combined with HTTP/2's header compression and multiplexing, gRPC calls typically have lower latency and CPU overhead than equivalent JSON-over-HTTP/1.1 REST calls, which matters at high internal call volumes.
Cricket analogy: Server streaming, where one request yields a continuous stream of responses, is like requesting 'live score updates' and receiving a running feed of every ball bowled rather than one static snapshot.
// pricing.proto
syntax = "proto3";
package pricing.v1;
service PricingService {
rpc GetPrice (PriceRequest) returns (PriceResponse);
rpc StreamPrices (PriceRequest) returns (stream PriceUpdate);
}
message PriceRequest {
string product_sku = 1;
}
message PriceResponse {
string product_sku = 1;
double price = 2;
string currency = 3;
}
message PriceUpdate {
string product_sku = 1;
double price = 2;
int64 timestamp_ms = 3;
}gRPC's binary payloads and HTTP/2 requirement make it harder to debug with plain curl or browser dev tools, and browsers can't call gRPC servers directly without a gRPC-Web proxy layer. Reserve gRPC for internal service-to-service traffic, and keep REST or GraphQL at the public-facing edge where broad tooling compatibility matters more.
Because .proto files are versioned artifacts, teams often publish them to a shared schema registry or a dedicated Git repository, so every service consuming the pricing API compiles against the exact same, reviewed contract.
- gRPC uses Protocol Buffers over HTTP/2 to provide fast, strongly typed, binary RPC between services.
- .proto files define messages and services once, and generate client/server code in multiple languages from a single source of truth.
- Numbered fields in Protocol Buffers make the wire format compact and fast to parse compared to JSON.
- gRPC supports unary, server-streaming, client-streaming, and bidirectional-streaming call types.
- HTTP/2 multiplexing lets many gRPC calls share one TCP connection efficiently.
- gRPC is best suited for internal, high-volume service-to-service traffic rather than public browser-facing APIs.
- Debugging gRPC requires specialized tooling since payloads are binary, unlike human-readable JSON over REST.
Practice what you learned
1. What transport protocol does gRPC build on?
2. What is the role of a .proto file in gRPC?
3. Which gRPC call type would best fit a live stock price feed sent continuously after one subscription request?
4. Why is gRPC generally not recommended for public browser-facing APIs?
5. What makes Protocol Buffers' wire format more compact than typical JSON payloads?
Was this page helpful?
You May Also Like
REST Between Services
Learn how RESTful HTTP APIs model resources, relationships, and versioning to provide a predictable, language-agnostic contract for synchronous microservice communication.
Synchronous vs Asynchronous Communication
Understand the fundamental trade-off between blocking request-response calls and non-blocking message-based communication between microservices, and when to choose each.
Event-Driven Communication
Understand how publishing and subscribing to events decouples microservices in both time and knowledge, and the trade-offs between choreography and orchestration.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 40 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics
Software EngineeringSystem Design Study Notes
Architecture · 40 topics