Compare

REST vs gRPC

RESTA request per update

DeliveringOrder #981

To Home · Indiranagar, BLR-07

Sharing location0 MB this hour

Rider serviceREST API
Dispatchassigns
Customer’s map
gRPCOne stream that stays open

DeliveringOrder #981

To Home · Indiranagar, BLR-07

Sharing location0 MB this hour

Rider servicegRPC
Dispatchassigns
Customer’s map

Ravi’s rider app sends his location every second, so the customer can watch him on the map: a REST request for each update, or one gRPC stream that stays open. Then a new order comes, and half the riders haven’t updated their app. Illustrative sizes.

Compare next

TCP vs UDPSSE vs WebSocket

REST or gRPC?

REST for public APIs and browsers: simple, readable, supported everywhere. gRPC between services, and for apps that stream: smaller messages, both directions on one connection, and a contract that keeps old app versions working. Many companies use both.

Compare next

TCP vs UDPSSE vs WebSocket
DifferenceRESTgRPC
Each location updateA new request: headers + JSON, ~793 BA message on an open stream, ~40 B
Data per hour (1 update/s)~2.9 MB~0.14 MB
Server → appCan’t; the app pollsThe same stream, both ways
Old app versionsEach JSON shape handled by handField numbers keep them working
ContractDocs (OpenAPI if you add it).proto; code generated for every app and service
From a browserWorks nativelyNeeds gRPC-Web and a proxy
Best forPublic APIs, browsers, partnersServices, and apps that stream

REST vs gRPC, explained step by step

1. Ravi’s location

Ravi is bringing a Zepto order, and his rider app sends his location every second, so the customer can watch him on the map. On the left, the app uses REST: a separate request for every update. On the right, gRPC: one stream that stays open. Let’s put both through three situations.

First, the location itself. With REST, every second the app sends a new request: headers and JSON, about eight hundred bytes with the reply. On a weak signal the requests queue up, and Ravi jumps across the customer’s map.

With gRPC, the app opens one stream and keeps it. Each update is a tiny binary message, about forty bytes, so Ravi glides along the map, and his phone uses a twentieth of the data.

2. A new order

Next, a new order is ready for Ravi. REST can’t call his phone, so the app keeps asking: any new order? Every five seconds. Most answers are no, and the order can wait five seconds to reach him.

With gRPC, the stream goes both ways. The server sends the order down the same stream the moment it’s assigned, and Ravi sees it at once.

3. Old app versions

Finally, a new app version renames the location fields, but half the riders haven’t updated. With REST, the server gets two kinds of JSON, and any rider it doesn’t handle by hand freezes on the map.

With gRPC, fields travel as numbers from a shared contract. A renamed field keeps its number, so old and new apps both keep working.

In short

So which should you pick? REST for public APIs and browsers: simple, readable, and supported everywhere. gRPC between services, and for apps that stream: smaller messages, both directions on one connection, and a contract that keeps old versions working. Many companies use both.