What is gRPC?

gRPC was created by Google as an open source, high-performance remote procedure call framework to be used in virtually any type of environment. gRPC can connect services within 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 (like apps on mobile devices) to back-end services.

gRPC is not a new concept. In fact, it was adopted from remote procedure call RPC and gained significant popularity within a few years.

What is a remote procedure call?

Before we delve deeper 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. See how it works:

1. A client sends a request message to a remote server to perform a specific procedure.
2. The remote server sends a response to the client
3. The client application receives the response and can continue with the process.

It's that simple. A request from the client, a response from the server, and the requesting client can then proceed with the action in question.

Without this communication between clients and servers, applications that rely on remote data or functions would not work.

There are two main problems with RPC:

• The RPC communication process is hidden from the user and (sometimes) the system, which leads to a “who is the client and who is the server” situation.
• RPC often omits many of the protocol's layers to improve performance, making it less secure.

With gRPC, the framework declares the service in a language-independent 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 that the server is on the same machine. This is partially achieved by the way 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 designed to communicate with each other over a network or to store data.

What is gRPC

Originally, everyone assumed that the “g” in gRPC stood for “Google.” To avoid this, Google changes the meaning of the “g” in every version it releases, so that no one really knows what the “g” means. Regardless of the nomenclature, gRPC has become incredibly popular. Why? Because gRPC:

• It makes abstraction incredibly easy.
• It is supported by a large number of programming languages.
• It is 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 in the world of microservices that gRPC really shines.

What is a microservice?

Before we continue, let's define microservices. Simply put, a microservice is an architecture that enables fast, frequent, and reliable delivery of complicated applications and services at scale. Instead of relying on monolithic services, microservices build systems by “aggregating” single-function modules that work together to form a complex service.

These single-function modules must have means of communicating with each other. This is where gRPC comes into play.

With microservices, you have several pieces that must interact. When using gRPC in microservices, developers don't need to write extra documentation for their projects because gRPC code is generally self-explanatory. Additionally, gRPC includes several libraries to support most functions. So it's not just easier to write, it's a more widely supported communications protocol.

What makes gRPC such a great communication protocol?

One of the most important reasons gRPC is such a performant system is because it is very good at using 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. Therefore, a new connection will not be necessary for each request/response. This not only makes HTTP2 more efficient, but also makes it more efficient 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 the client or server.
• gRPC can work with 3 types of streaming: Server Streaming (where the client sends a single request and the server can return multiple responses), Client Streaming (where the client sends multiple requests and the server sends back a single response) and Bidirectional Streaming (where the client and 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 able to cancel a gRPC call if 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 ways to communicate with each other efficiently and reliably, your best bet is gRPC.

And because gRPC supports many languages ​​(such as C#, Java, Go, Node.js, Python, Ruby, and PHP), you can be sure that any project you're working on supports this great communications framework.