Demystifying gRPC
If you’re in the software industry for the last few years, you must be familiar with SOAP, GraphQL, RESTful web services but since 2015, gRPC has been gaining traction slowly and turning heads in the industry due to its low latency inter-service communication.
What is a RPC? Simply put, its a Remote Procedure Call, which means when a procedure in another address space (another compute) could be invoked from a different address space as if that procedure call was a local one.
gRPC is a high performance RPC framework/technology built by Google and uses HTTP/2 instead of HTTP/1.1 and “Google’s own” protocol buffers instead of XML or JSON for data contract.
What is a Protobuf, you ask? “Protocol Buffers” is a open-source message format for data serialization, as the default method of communication between client and server.
JSON/XML vs Protobuf ! Advantages and its disadvantages
gRPC = HTTP/2 + Protobuf. So, How is it faster than REST ?
Lets dig deep into why Google and Uber uses gRPC for building their low latency systems.
HTTP/1.1
- Headers are sent at every request and are plaintext.
- Each request opens a TCP connection, hence adding to latency and increase in network packet size.
HTTP/2
- HTTP/2 supports multiplexing, i.e Client and Server can push messages in parallel over same TCP connection, which reduces latency.
- HTTP/2 supports server push. Server can push streams (multi-messages) for one request from client.
- HTTP/2 supports header compression.
- HTTP/2 is binary. (Protobuf is a binary protocol and makes a great match for HTTP/2)
- HTTP/2 is secure.
To summarise, in HTTP/2, there is less chatter, less use of bandwidth, reduced latency and increased security.
Types of API in gRPC:
- Unary — Simple client server communication
- Server Streaming — This is the case where client will send a single request and server can send back multiple response. Example of this: When client send request for homepage with multiple item list, server can send back responses separately, making client enable lazy loading.
- Client Streaming — Here, client will send multiple requests and server will only send back a single response. Example of this: Zip/chunk files upload by client.
- Bidirectional Streaming — This is streaming where both client and server will sequences of message all together without waiting for the response.
message GreetRequest {
string name = 1;
string description = 2;
int32 id = 3;
}
message GreetResponse {
string processedMessage = 1;
}
service GreetService {
//Unary
rpc greet(GreetRequest) returns (GreetResponse) {};
//Server Streaming
rpc greetManyTimes(GreetManyTimesRequest) returns (stream GreetManyTimesResponse) {};
//Client Streaming
rpc longGreet(stream LongGreetRequest) returns (LongGreetResponse) {};
//Bi-directional
rpc greetEveryone(stream GreetEveryoneRequest) returns (stream GreetEveryoneResponse) {};
}gRPC vs REST vs GraphQL. Who wins?
Please note that gRPC is not a replacement for REST or GraphQL, it is another technology option which is based on RPC having its own advantages and disadvantages and one must evaluate the different technologies to suit their business needs.
Get Debmalya Pan’s stories in your inbox
Join Medium for free to get updates from this writer.
REST vs gRPC — Benchmark Tests:
I am adding the references of couple of other medium articles which explains the benchmark tests performed.
References:
- https://medium.com/@i.gorton/scaling-up-rest-versus-grpc-benchmark-tests-551f73ed88d4
- https://medium.com/@EmperorRXF/evaluating-performance-of-rest-vs-grpc-1b8bdf0b22da
When to use gRPC?
- Internal Systems especially service to service synchronous communication — Since gRPC uses HTTP/2 and protocol buffers it offers better performance, less bandwidth requirements.
- Real time data streaming — As gRPC supports client side, server side and bi-directional streaming under HTTP/2. This makes it well suited for applications like ride share applications, etc.
- Native Mobile applications backend — As gRPC offers small payload size and more speed, it can enhance the user experience and reduce the latency and bandwidth.
When to not use gRPC? Drawbacks of gRPC!
- Browser based apps — It is not possible to call gRPC APIs directly from browsers owing to lack of full support for HTTP/2 by browsers. Though there is gRPC-web proxy available through which browser based application can consume gRPC APIs, but again there are certain limitations and hence for a pure browser based apps gRPC is not well suited for now.
- Legacy Systems — Scenarios where integration is required with legacy systems, gRPC will not be a right fit there as legacy system may not support gRPC.
- gRPC is not a replacement for WebSockets, since WebSocket is designed more for web browser to server communication whereas gRPC is more suited for server-to-server communications.
What I shared here is just the surface of gRPC, but this should help you guys to understand about what gRPC is and what does it provides, how it roughly works. I hope to explain how to implement a gRPC service using SpringBoot in a future article.
Resources:







