gRPC is fast, robust, and is gaining more supporters. Companies like Google, Netflix, and Dropbox already use it in production. Should you be interested in this? I’ll try to help you make the decision by explaining what it is and discussing major pros and cons.
What is gRPC?
gRPC is a modern, language-agnostic, high-performance framework that’s an evolution of old RPC (Remote Procedure Call) protocol. Initially designed by Google, now it’s an open-source project designed for communication between services. It runs on top of HTTP/2 protocol to transport binary messages.
Protocol Buffer
In order to be consumed, gRPC service must define a contract for its clients (contract-first approach). By default, it uses Protocol Buffer (also known as Protobuf – *.proto) as the Interface Definition Language (IDL) files to describe operations and payloads. Thanks to IDL, gRPC framework does not enforce any specific language, as *.proto files can be used to generate language or platform-specific stubs for clients and servers, allowing multiple different platforms to communicate. Example Protobuf file below:
// Version of Proto file
syntax = "proto3";
// Option specific to .NET Protocol Buffer compiler
// to provide namespace for Service generated code
option csharp_namespace = "Grpc.Services";
// Our service definition
service Ordering {
rpc CreateOrder(CreateOrderRequest) returns (CreateOrderResponse);
}
// Type for input parameter
message CreateOrderRequest {
string customerName = 1;
bool isActive = 2;
}
// Returned type
message CreateOrderResponse {
string orderId = 1;
}
gRPC vs REST
A lot of developers have been working with RESTful services (either front-end or back-end side). A comparison of gRPC to RESTful services seems reasonable. Let’s discuss following topics:
Communication
An obvious difference is transport protocol – gRPC uses HTTP/2 with Protocol buffer, which is binary formatted, while RESTful services are usually (you can make it in HTTP/2, but that’s another story) based on HTTP/1.1 with JSON payloads, which are text-based and larger. This involves performance, gRPC using HTTP/2 is simply much faster.
Streaming in gRPC is bidirectional, which means that client and server can read and write messages in any order, while in REST, client sends 1-way request to the service.
Contract
As mentioned before, gRPC is contract-based, which means that client is fully dependent on the contract defined by gRPC service. You can compare it to WCF (Windows Communication Foundation), where services had to keep their definition in WSDL, whereas gRPC does basically the same using IDL – Protocol Buffer files.
REST services are not required to define anything upfront. Of course, nowadays we have Open API specifications describing RESTful services, but they’re purely an aid for consumers.
Approach
Key point in RESTful services is referring to their resources (entities) and defining the way of resource manipulation by proper HTTP methods (GET/POST/PUT/PATCH/DELETE).
The approach of gRPC services is to allow clients to remotely invoke operations/procedures.
Is gRPC an alternative to REST Services?
Everything suggests that gRPC is slowly taking the market. But I would be very cautious in saying that it’s a great alternative for every purpose.
Downsides
It has limited browser support. There is gRPC-Web, but web applications have to still call a proxy like Envoy to translate HTTP/1.1 request to HTTP/2 for service-to-service traffic. But still, it’s done without having to write any custom REST API. Also, Proto files can be translated to Javascript clients pretty easily.
Where it shines
- Microservices
gRPC is designed for low latency and high throughput communication. Also, microservices that need to communicate with each other in synchronous fashion usually have wide knowledge about operations they expose, therefore a clear contract can be a significant plus. - Real-time communication scenarios
gRPC has support for bi-directional streaming. Services requiring point-to-point communication can do that without polling. - Network constrained environments
gRPC message will be always smaller than JSON (text-based) one. Very important in scenarios, where network consumption can play a huge role – i.e. mobile applications.
So is it?
An alternative? Definitely. Always the best one? Not necessarily.
Communication between microservices – this is where it excels. It’s an upgrade in almost every aspect. I don’t see any reason for not using it in greenfield projects. Switching to it in legacy APIs? It depends if greatly increased performance or bidirectional streaming will be an added value.
For APIs being a typical back-end for external world clients? It depends. For apps, where network bandwidth consumption is crucial, it’s something worth considering. But remember, gRPC-Web doesn’t give everything that gRPC can offer.
More to read
