REST Talks in Plain Text. gRPC Talks in Binary. That's Why It's 7x Faster.

#grpc #api #restapi #devops

Every API in this series so far has been designed with humans in mind. REST responses are readable JSON. GraphQL queries look almost like English. Even WebSocket messages are usually strings you can read in a browser console.

gRPC wasn't designed for humans to read. It was designed for machines to process as fast as possible. That single design decision is why Google built it, why every major tech company runs it internally, and why you've never seen it on a public API.

The Problem gRPC Solves

A large application isn't one server. Zomato has an order service, a payment service, a notification service, a restaurant service, a delivery tracking service — all running separately, all calling each other constantly. Every millisecond those services spend waiting on each other adds up to latency the user feels.

With REST, every call serializes data into JSON (human-readable text), sends it over HTTP/1.1 (one request at a time per connection), and the receiving service deserializes it back into objects. At low volume this is fine. At thousands of calls per second between dozens of services, the JSON parsing overhead alone becomes a measurable performance cost.

gRPC solves this by replacing two things: the data format and the transport protocol.

How gRPC Works

Instead of JSON, gRPC uses Protocol Buffers (Protobuf) — a binary format where data is encoded as compact bytes rather than readable text. You define your data structure once in a .proto file:

// Define your message structure once — both services use this contract
message OrderRequest {
  string order_id = 1;
  string user_id  = 2;
  float  amount   = 3;
}

message OrderResponse {
  bool   success = 1;
  string message = 2;
}

// Define the service and its methods
service OrderService {
  rpc PlaceOrder (OrderRequest) returns (OrderResponse);
}

From this file, gRPC auto-generates client and server code in whatever language you're using. The two services never write manual API calls — they call each other like local functions, with full type safety enforced at compile time.

Instead of HTTP/1.1 (one request per connection), gRPC runs on HTTP/2, which supports multiplexing: thousands of simultaneous requests over a single connection.

Four Ways gRPC Can Communicate

REST has one pattern: request, response, done. gRPC has four.

Unary works exactly like REST: one request, one response. This is the default and the simplest.

Server Streaming lets the server send multiple responses to a single request. Live order tracking is a perfect example: you ask once "where is my order?" and the server keeps pushing location updates as the delivery moves.

Client Streaming lets the client send multiple requests before the server responds once. Useful for uploading a large file in chunks: send chunk after chunk, server assembles them, responds when done.

Bidirectional Streaming keeps both sides sending freely at the same time, like a WebSocket but with typed schemas and HTTP/2 multiplexing underneath.

When to Use gRPC, When Not To

Use gRPC when services inside your system need to talk to each other at high frequency and performance matters. It's also ideal when you need streaming (server push, client upload, or bidirectional) with strict type contracts between services.

Skip gRPC when you're building a public API, a browser-facing endpoint, or anything where developers need to read and debug requests easily. Protobuf is binary — you can't read it in a browser's Network tab. REST stays cleaner for anything consumer-facing.

What You Now Understand

REST is optimised for humans reading and writing APIs. gRPC is optimised for machines calling each other as fast as possible. Binary over text. HTTP/2 over HTTP/1.1. Auto-generated type-safe clients over hand-written fetch calls.

You'll rarely build a gRPC API from scratch early in your career. But you'll work inside systems that use it, and now you understand why it exists, what it's doing, and why it's faster than everything you've used before.

Your next step: look up how companies like Netflix, Uber, or Dropbox describe their internal microservice architecture. gRPC shows up in almost every one. Reading a real engineering blog post about it, now that you have the mental model, is a completely different experience.

DEV Community