gRPC: What? Why? When?
As the title suggests, in this article I am going to talk about the three Wh-questions of gRPC:
- What is gRPC?
- Why to use gRPC?
- When to use gRPC?
What is gRPC?
gRPC stands for gRPC Remote Procedure Calls. It is a language agnostic, high-performance RPC framework. As per grpc.io official website, “gRPC is a modern, open source remote procedure call (RPC) framework that can run anywhere. It enables client and server applications to communicate transparently, and makes it easier to build connected systems”. It is created and used by Google and is also a part of Cloud Native Computing Foundation (CNCF) project.
In simple words, In gRPC, a client application can directly call a method on a server application on a different machine as if it were a local object, making it easier to create distributed applications and services. As in many RPC systems, gRPC is based around the idea of defining a service, specifying the methods that can be called remotely with their parameters and return types. On the server side, the server implements this interface and runs a gRPC server to handle client calls. On the client side, the client has a stub that provides the same methods as the server. You can read more about it on Google’s website: Introduction to gRPC.
Why to use gRPC?
gRPC has many advantages which can make you choose it for your next distributed applications and services development. Here are few of strengths of gRPC.
- It is a modern open source high performance Remote Procedure Call (RPC) framework that can run in any environment.
- It is built upon HTTP/2.0.
- It uses protocol buffers as its Interface Definition Language (IDL) and as well as its underlying message interchange format. This enforces contract-first API development. This also reduces network usage with Protobuf binary serialization and makes it significantly fast(5 to 8 times faster than REST).
- It has tooling support(native code generation support) available for many languages to generate strongly-typed servers and clients.
- It supports client, server, and bi-directional streaming calls.
- It has pluggable support for load balancing, tracing, health checking and authentication.
- It provides frameworks, libraries, and code-generation and this makes development very easy. On both the server and client side, it generates the boilerplate code. Developer has to just focus on the actual implementation. (To generate and understand about boilerplate code(for dotnet), you can check this article.)
For further understanding about why you should choose gRPC for your next project, Please check these inks:
- Why milliseconds matter: This blog explains in detail with multiple tests that how fast is gRPC.
- Compare gRPC services with HTTP APIs: This Microsoft documents talks about different strengths of gRPC.
- gRPC vs REST: This blog post from Google provides a comparative explanation of gRPC, REST and OpenAPI.
When to use gRPC?
At this point you must gave understood about what is GRPC and why to use it. Now you might be thinking of everything is working good with REST, then why I should use/switch to gRPC. The last section might have answered a bit about that. To add further to that, Please take a look at below image which provides a high level comparison between gRPC and REST.
As the above image suggests, gRPC uses HTTP2 by default. It uses Protobuf which makes it type-safe and significantly faster than REST. It supports Client, Server and Bidirectional streaming which is not in REST. It also supports client code generation which is not easily available in case of REST. So considering all this, my answer to ‘When to use gRPC’ is now and now onwards.
But as REST is widely used and it has a great browser support, I would suggest not to replace all REST services with gRPC. Instead there are few cases where gRPC can excel and in few cases REST would work. Let’s see what all are the scenarios where one should choose gRPC:
- Microserveices: gRPC’s low-latency and high-speed throughput communication makes it a better choice in microservice architecture. By using gPRC, Lightweight microservices can transmit messages efficiently and with high speed. This can improve the overall application’s performance.
- Polyglot systems(Multi-language systems): When multiple languages are required for development, gRPC’s native code generation support for a wide range of development languages comes handy. It can generate server’s as well as client’s boilerplate code. Native code generation capability also makes it type safe and hence less error-prone.
- Point-to-point real-time Streaming: When real-time communication is a requirement, gRPC’s ability to manage client, server and bidirectional streaming allows system to send and receive messages in real-time without waiting for Unary client-response communication.
- Low-power low-bandwidth networks: gRPC’s serialized Protobuf messages offers light-weight messaging, greater efficiency and high speed(especially when compared to JSON). For bandwidth-constrained and low-power networks like IOT based connected devices or mobile/browser based applications from remote areas, it can provide a remarkably better performance.
I hope you have got the answers to the thee Wh-questions of gRPC: What, why and When.
For more in-depth knowledge, Please check these other articles about gRPC by me:
