Microservices / Networking / Service Mesh / Sponsored / Contributed

gRPC Remote Procedure Calls in a Nutshell

19 Nov 2020 12:00pm, by

WSO2 sponsored this post.

Kasun Indrasiri
Kasun is the director of integration architecture at WSO2 and is an author/evangelist on Microservices Architecture and Enterprise Integration Architecture. He has authored Microservices for Enterprise and Beginning WSO2 ESB. He is an Apache committer and has worked as the product manager and an architect of WSO2 Enterprise Integrator/ESB.

We are pleased to announce the new release of our book, gRPC: Up and Running, published by O’Reilly Media. gRPC (gRPC Remote Procedure Calls) is one of the most popular inter-process communication protocols in the modern microservices and cloud native era. With the increasing adoption of gRPC, we thought it was important to write a book on gRPC and share our experience of building cloud native microservices apps with it.

So, before we dive into the details of the book, let me give you a brief overview of what gRPC is.

gRPC is modern inter-process communication technology that can overcome most of the shortcomings of the conventional inter-process communication technologies, such as RESTful services. Owing to the benefits of gRPC, most modern applications and servers are increasingly converting their inter-process communication protocols to gRPC.

The foundation of a gRPC-based application is the service and service interface definition. When you develop a gRPC application, the first thing that you will do is define a service interface — which contains information on how your service can be consumed, what methods you allow the consumers to call remotely, what are the method parameters and message formats to use when invoking those methods, and so on.

The language that we specify the service definition with is known as Interface Definition Language (IDL); and gRPC uses Protocol Buffers as the IDL. So, as shown in the example illustrated in figure 1, you define the service interface as a protocol buffer definition (ProductInfo.proto).

Figure 1: Interaction between a gRPC service and client application.

Once you design the service definition, you can generate the server-side code — known as server skeleton — which simplifies the server-side logic by providing the low-level communication abstractions. Also, you can generate the client-side code, which is known as client stub, which simplifies the client-side communication with the abstractions in order to hide the low-level communication for different programming languages. The methods that you are specifying in the service interface definition can be remotely invoked by the client-side as easily as making a local function invocation. By default, gRPC uses HTTP2 as the network communication protocol and layers the binary data based on the protocol buffer on top of HTTP2.

Why gRPC?

So, why would somebody select gRPC as the communication protocol when they have many other options available? Let’s take a closer look at some of the key advantages of gRPC.

  • Efficient: Unlike other common techniques such as a RESTful service, gRPC is not based on a textual format such as JSON. Rather it uses a binary protocol based on the Protocol Buffer. Hence it’s quite efficient.
  • Simple and well-defined service interfaces and schema: Owing to the contract-first approach of designing applications, the service interface and schema is not an afterthought. Before you develop anything, you need to have a well-defined service interface and corresponding schemas for messages that need to be exchanged.
  • Strongly typed: Having well-defined schemas helps to overcome most of the runtime and interoperability errors that you will encounter when you build cloud native applications that span across multiple teams and technologies.
  • Polyglot: The protocol fosters the use of the programming language of your choice, to develop applications with no limitations from the underlying protocol.
  • Duplex streaming: gRPC has native support for client or server-side streaming which is baked into the service definition itself. This allows gRPC to stand ahead of the competition with other technologies such as REST.
  • Built-in Commodity Features: gRPC offers built-in support for commodity features such as authentication, encryption, resiliency (deadlines and timeouts), metadata exchange, compression, load balancing, service discovery, and so on
  • Maturity and adoption: gRPC is being widely adopted and battle-tested. It is becoming the de-facto communication protocol for inter-service communication for microservices or cloud native applications.

We hope this gives you a basic understanding of what gRPC is and the importance of it as an inter-service communication protocol. Now let’s look at what motivated us to write a book on gRPC.

Why We Wrote gRPC Up and Running

With the increasing adoption of gRPC, we felt that developers needed a comprehensive book on gRPC. A book you can use as the ultimate reference guide in every stage of the development cycle of your gRPC applications. There are a lot of resources and code samples of gRPC all over the place (documentation, blogs, articles, conference talks, and so on), but there’s no single resource that you can use to build gRPC applications. Also, there aren’t any resources on the internals of gRPC protocol and how it works under the hood.

We wrote this book to overcome those challenges and to give you a comprehensive understanding of the fundamentals of gRPC, how it differs from conventional inter-process communication technologies, real-world communication patterns of gRPC, building gRPC applications using Go and Java, how it works under the hood, how to run gRPC applications in production, and how gRPC works with Kubernetes and rest of the ecosystem.

So, I hope this article gives you a high-level understanding of gRPC as well as some insights on our new book. Please check it out and try out the examples.

Feature image via Pixabay.

A newsletter digest of the week’s most important stories & analyses.