A postal service where every postcard has a strict template. The address fields are always in the same spot. The message area has specific sections for specific types of information. Both sender and receiver have matching templates, so there’s never confusion about what goes where. This postal service is fast - postcards arrive almost instantly - and efficient - you can send thousands in the time traditional mail delivers one. That’s gRPC.
The Traditional Mail Room (REST/JSON)
In the traditional system, you write letters freehand:
“Dear Server, I would like to know the weather for Seattle. Sincerely, Client”
The server reads your letter, interprets your handwriting, figures out what you want, and writes back:
“Dear Client, The weather in Seattle is: { ‘temperature’: 65, ‘condition’: ‘rainy’, ‘humidity’: 80 } Best regards, Server”
This works, but notice the overhead: greetings, signatures, and the need to parse human-readable text. What if you misspell “temperature” as “temprature”? The server might not understand.
The gRPC Postcard System
With gRPC, you use pre-printed postcards with specific fields:
[WEATHER REQUEST POSTCARD #001]
City: [Seattle ]
Date: [2025-03-14 ]
Fields: [✓] Temperature
[✓] Condition
[✓] Humidity
[ ] Wind Speed
The server has the matching template and fills in a response postcard:
[WEATHER RESPONSE POSTCARD #001]
Temperature: [65]
Condition: [Rainy]
Humidity: [80]
No ambiguity. No parsing errors. No wasted space.
The Magic of Protocol Buffers
The postcards are Protocol Buffers (protobuf). You define the template once:
The Weather Request template specifies:
- Field 1: The city name (text)
- Field 2: The date (text)
- Field 3: Which weather fields you want (a list)
The Weather Response template contains:
- Field 1: Temperature (number)
- Field 2: Condition description (text)
- Field 3: Humidity percentage (number)
Each field has a number, like labeled boxes on a form. Both client and server use this same template. It’s like having a printing press that creates identical postcards for everyone.
Why Postcards Are Faster
This diagram requires JavaScript.
Enable JavaScript in your browser to use this feature.
The efficiency gains are measurable:
Size: A JSON message saying {"temperature": 65} might be 20+ bytes. The same in protobuf? Just 3 bytes.
Speed: No text parsing. Binary data maps directly to memory structures.
Type Safety: Can’t put a string where a number should go - the postcard won’t allow it.
Versioning: Add new fields to postcards without breaking old ones.
Streaming Postcards
Here’s where gRPC gets interesting. Instead of single postcards, you can stream them:
Server Streaming: “Send me weather updates every hour”
- Client sends one request postcard
- Server sends a stream of response postcards
Client Streaming: “Here are 100 cities, tell me the average temperature”
- Client sends a stream of request postcards
- Server sends one response postcard
Bidirectional Streaming: “Let’s have a weather conversation”
- Both send streams of postcards back and forth
It’s like having a conveyor belt between mailboxes.
The Postcard Printing Press (Code Generation)
You don’t hand-write code for these postcards. The protobuf compiler generates code in any language:
You run the protobuf compiler (protoc) with your template file:
- For Go: It generates Go code that understands the postcards
- For Python: It creates Python classes matching the template
- For Java: It produces Java classes with the same structure
- For any supported language: Perfect translation, no errors
Every language gets perfectly matching postcards. No translation errors.
When to Use the Postcard System
gRPC postcards excel when you need:
Speed: Binary encoding beats text parsing Type Safety: Contracts enforced at compile time Streaming: Continuous data flows Polyglot Services: Different languages working together Mobile/IoT: Bandwidth efficiency matters
When to Stick with Letters
Traditional REST/JSON letters are better for:
Web Browsers: They can’t send binary postcards (easily) Public APIs: Developers expect JSON Simple Services: Postcards need printing presses (setup overhead) Debugging: Humans can read JSON letters
The Network Express
gRPC uses HTTP/2, which is like having multiple mail trucks on the same route. Traditional HTTP/1.1 sends one letter, waits for response, sends another. HTTP/2 sends multiple postcards simultaneously on the same connection.
Real-World Postcard Routes
Major companies use gRPC postcards for internal communication:
- Google: Billions of gRPC calls per second
- Netflix: Streaming service communication
- Square: Payment processing
- Uber: Real-time location updates
When milliseconds and megabytes matter, postcards beat letters.
Decision Rules
Use gRPC when:
- You’re building internal service-to-service communication
- You control both sides of the interface
- You need streaming (server, client, or bidirectional)
- Bandwidth is constrained (mobile, IoT)
- Type safety across language boundaries matters
Use REST/JSON when:
- You’re building public APIs
- Browser clients need to consume the service
- Debugging by humans is a priority
- You need maximum ecosystem compatibility
gRPC transforms service communication from writing prose to filling forms. By standardizing message formats, using binary encoding, and leveraging HTTP/2, it achieves remarkable efficiency. The tradeoff: you need that printing press (protobuf compiler) and both sides must agree on postcard formats.
When you need speed, type safety, and streaming capabilities, gRPC’s structured postcards deliver messages at light-speed with laser precision.
