What is gRPC and when would you use it?
Who controls the response shape
In REST the server decides the response shape, in GraphQL the client builds it, and in gRPC a compiled contract sets it. The trade-offs come from who decides the shape.
For this question · chapter 3 of 3
The contract compiles the call
- In gRPC, a file checked into the repository beside the code decides the response shape. That file, orders.proto, names one service, one method, and the message the server returns. The number after each field in the message is what gets sent over the network. So once a field has the number 2, that field must keep the number 2 forever.
- In gRPC, a mismatch between client and server is now a compile error. The compiler writes the client and server stubs from one file, so nobody types them by hand and they cannot get out of sync. Rename product_name in the file, and both projects stop compiling. A REST client would have found the same mistake in production, when a user reported a 400 error.
- gRPC is fast for two reasons, and both matter. First, gRPC encodes messages with protobuf, a binary format that writes the field number 2 where JSON writes the text total_cents. So the same three fields take 22 bytes instead of 61. Second, HTTP/2 sends the four calls over one connection instead of four separate connections, so no call waits in a queue behind another call.
- The gRPC contract file covers more than the fields. It also decides how many messages each call sends. A REST endpoint gives you only one of the four call shapes, called unary: one message out and one back. The other three keep the stream open: one out and many back, many out and one back, or both directions at once. With REST, you build those three yourself.
- gRPC has a cost in the browser, because the browser cannot make a gRPC call on its own. The browser's fetch API cannot set the HTTP/2 frames that gRPC needs. So a grpc-web proxy between the browser and the server has to translate each call. The browser's network tab shows 22 bytes of binary, not a body you can read. This cost is why gRPC is used inside a system.
- No single choice of who decides the shape fits every caller, so a real system runs REST, GraphQL and gRPC together. REST runs at the public edge, because any client can call a REST endpoint and a CDN can cache REST responses. GraphQL runs where many screens each want their own response shape, and you would rather not deploy again for each screen. gRPC runs between your own services, where both ends are your code and the contract compiles.
In gRPC, a file checked into the repository beside the code decides the response shape. That file, orders.proto, names one service, one method, and the message the server returns. The number after each field in the message is what gets sent over the network. So once a field has the number 2, that field must keep the number 2 forever.
Answer with who controls the response shape, not with a feature list. In REST the server controls the shape of each endpoint, so you get fixed shapes and extra round trips. In GraphQL the client controls the shape of each query, so you lose HTTP caching and must handle the N+1 problem and query cost. In gRPC a contract compiled into both client and server controls the shape, so you lose direct browser calls and readable messages. Finish by saying that most real systems run all three, and where you would put each one.
© LearnThatStack - diagrams may not be republished without permission.
Want a quick review of the fundamentals? See the API Design cheatsheet.
74 of 92 API Design answers are in Pro.
Full answers, code samples, and AI explanations that go simpler or deeper. Cancel anytime.
- Full answers + code
- AI explanations, simpler or deeper
- 1,000 AI credits / month
- Cancel anytime