gRPC was created by Google, as an open-source, high-performance Remote Procedure Call framework to be used within just about any type of environment. gRPC can connect services inside or across data centers and has pluggable support for load balancing, tracing, health checking, and authentication. You can even use gRPC in the “last mile” of distributed computing, to connect remote services (such as apps on mobile devices) to backend services.
gRPC isn’t a new concept. In fact, it was adopted from Remote Procedure Call RPC and has gained significant popularity in a few short years.
What is a Remote Procedure Call?
Before we dive further into gRPC, let’s find out what exactly a Remote Procedure Call is. RPC is a form of client-server communication that relies on a function call instead of the usual HTTP call. Here’s how it works:
- A client sends a request message to a remote server to execute a specific procedure.
- The remote server sends a response to the client
- The client application receives the response and can proceed with the process.
It’s that simple. A client request, a server response, and the requesting client can then proceed with the action at hand.
Without this communication between clients and servers, apps that depend on remote data or functions wouldn’t work.
There are 2 main problems with RPC, though:
- The RPC communication process is hidden from the user and (at times) the system, which leads to a “who is the client and who is the server” situation.
- RPC often omits many of the protocol layers to improve performance, thereby making it less secure.
With gRPC, the framework declares the service in a language-agnostic Interface Definition Language (IDL) and then generates language-specific bindings. The big difference between RPC and gRPC is that gRPC is designed to make the client believe the server is on the same machine. This is partly achieved by how the protocol uses serialization.
gRPC makes it possible for any custom data type that requires serialization to be defined as a Protocol Buffer, which is an open-source, cross-platform library used to serialize structured data. Protocol Buffers are useful for applications that are designed to communicate with one another over a network or for storing data.
What is gRPC
Originally, everyone assumed the “g” in gRPC stood for “Google.” To avoid that, Google changes the meaning of the “g” in each version they release, so no one actually knows what the “g” stands for. Regardless of nomenclature, gRPC has become incredibly popular. Why? Because gRPC:
- Makes abstraction incredibly easy.
- It’s supported by a large number of programming languages.
- It’s a performance-centric protocol.
- It’s much easier to use (and more reliable and secure) than typical HTTP calls.
- It is widely used in microservices.
It’s within the world of microservices that gRPC really excels.
What is a microservice?
Before we continue on, let’s define microservice. Simply put, a microservice is an architecture that enables the rapid, frequent, and reliable delivery of complicated applications and services at scale. Instead of depending on monolithic services, microservices build systems by “bundling” single-function modules that work together to form a complex service.
These single-function modules must have the means to communicate with one another. That’s where gRPC comes into play.
With microservices, you have several pieces that must interact. By making use of gRPC in microservices, developers don’t have to also write extra documentation for their project, because the gRPC code is often self-explanatory. On top of that, gRPC includes multiple libraries to support most functions. So it’s not only easier to write, it’s a more widely supported communication protocol.
What makes gRPC such a good communication protocol?
One of the most important reasons why gRPC is such a performant system is because it’s very good at making use of HTTP2.
The big advantage of HTTP2 over HTTP is that the second iteration makes it possible to send multiple requests and receive multiple responses simultaneously. Because of this, a new connection will not be required for each request/response. Not only does this make HTTP2 more efficient, but it also makes it more performant and reliable.
Other reasons why gRPC is superior include:
- gRPC also makes use of metadata. Instead of relying on HTTP request headers, metadata works with key-value data that can be set on either the client or the server-side.
- gRPC can work with 3 types of streaming: Server Streaming (where the client sends a single request and the server can then return multiple responses), Client Streaming (where the client sends multiple requests and the server sends back a single response), and Bidirectional Streaming (where both the client and the server send simultaneous messages without waiting for a response).
- gRPC uses interceptors that allow you to intercept and modify requests and responses.
- gRPC is capable of using load balancing (and is implemented in the GoLang language).
- gRPC clients are capable of canceling a gRPC call, on the off chance the client no longer requires a response.
When should you use gRPC?
The answer here is simple: When you’re building an application that is a collection of microservices, and those microservices require the means to efficiently and reliably communicate with one another, your best bet is gRPC.
And because gRPC supports so many languages (such as C#, Java, Go, Node.js, Python, Ruby, and PHP), you can be sure that whatever project you are working on supports this outstanding communication framework.
