gRPC – Paving the way to the client-server communication of the future

Network technology is rapidly advancing on a constant basis. To meet the increasing demands of distributed computer systems, a new system called gRPC was developed for remote procedure calls. The "g" stands for Google, which was instrumental in the development of gRPC. We’ll explain what gRPC is, how it works, and where it is used.

Contents

What is gRPC?
How gRPC works: multilingual and efficient thanks to protocol buffers and HTTP/2
gRPC workflow and first steps via protocol buffers
HTTP/2: High-performance streaming
Pros and cons of gRPC
Comparison of gRPC and REST
Where is gRPC used?

What is gRPC?

gRPC is a modern remote procedure call system that handles communication in distributed client-server architectures extremely efficiently using innovative methods. Like its predecessor RPC, it works at the process level. A key feature of inter-process communication using gRPC is the transparency principle: Remote instances interact so closely and smoothly, even at great distances, that their communication appears identical to local communication between internal machine processes.

gRPC was initially developed by Google in 2015. Today, the Cloud Native Computing Foundation is in charge of distributing and developing the communication technology. gRPC is open source, meaning the source code is publicly accessible. Third parties are permitted and encouraged to make changes and enhancements to the code.

By default, gRPC uses HTTP/2 for transporting data streams between remote computers. Protocol buffers developed by Google are used for processing the data. Protocol buffers are saved as simple text files with the extension .proto.

gRPC is frequently referred to as a framework. One useful feature of a framework is that it provides developers with a standard programming structure, saving time and effort. For example, the standardized framework of gRPC includes a variety of functions and elements that don’t have to be programmed from scratch every time. The gRPC framework also defines standardized interfaces to specific sources (such as databases).

How gRPC works: multilingual and efficient thanks to protocol buffers and HTTP/2

Protocol buffers (Protobuf) perform several functions in the gRPC system. They serve as an interface definition language (IDL) and describe an interface in a language-independent way. That means they aren’t bound to a specific programming language (such as Java or C). They also define the services to be used and the features provided. For each function, you can specify the parameters that are sent with a request and the type of return value that can be expected.

From the remote perspective, protocol buffers serve as the underlying message exchange format that defines message structures, types, and objects. They ensure that the client and server "understand" each other and operate as an optimally efficient functional unit over long distances.

The sequence of a gRPC call for a database query (for example, "Search for items in inventory") looks like this:

First, preparations are needed before the search can be completed. On the server side, a service and a gRPC server are implemented based on protocol buffers. The requesting client generates a matching stub. If the stub is available, the client application calls the corresponding function ("Search for items in inventory") in the stub.
The request is then sent to the server over the network. After receiving the request via a suitable service interface, the gRPC server starts the actual product search in the database.
The server then sends the response to the client stub, which forwards the return value to the original requesting instance (for example, "Number of items found").

Client- and server-side applications are sometimes written in different programming languages. gRPC overcomes these limitations through special interfaces and translation mechanisms.

In order to transport data streams back and forth between machines (Proto Request and Proto Response), HTTP/2 is embedded in special network protocols such as TCP/IP or UDP/IP. The streams transfer the compact binary data generated during serialization (marshalling), a standard process in remote procedure calls. The transmitted data is also deserialized (unmarshalling) so that the completely abstract data structures can be processed by the client and server in later steps.

Diagram of message exchange using gRPC in a client-server architecture — Message exchange via gRPC in a client-server architecture

gRPC workflow and first steps via protocol buffers

A typical gRPC workflow is divided into four steps:

Definition of the service contract for inter-process communication: The services to be set up as well as basic parameters and return types that can be called remotely are defined.
Generation of the gRPC code from the .proto file: Special compilers (command line tools called "protoc") generate the operative code from stored .proto files with the appropriate classes for the desired target language (such as C++ or Java).
Implementation of the server in the chosen language.
Creation of the client stub that calls the service. The request(s) are then handled by the server and client(s).

Diagram of the gRPC workflow — Basic steps of a gRPC workflow

For a database query that searches for a product in inventory, the first steps in the current protocol buffer syntax (version proto3) look like this:

syntax = "proto3";
package gRPC_service;
import "google/protobuf/wrappers.proto";
service InventoryService {
	rpc getItemByName(google.protobuf.StringValue) returns (Items);
	rpc getItemByID(google.protobuf.StringValue) returns (Item);
	 rpc addItem(Item) returns (google.protobuf.BoolValue);
}
 
message Items {
  string itemDesc = 1;
  repeated Item items = 2;
}
 
message Item {
	string id = 1;
	string name = 2;
	string description = 3;
}

The database query in the example uses the gRPC framework’s special wrapper libraries, which provide pre-programmed translation procedures that are imported at the beginning. These libraries ensure that incompatible interfaces can communicate with each other in multilingual and disparate client-server architectures. For example, you use these wrappers to generate the classes necessary for reading and writing messages.

The following diagram shows how the service definition (inventory.proto) controls the query of a database in a client-server architecture:

Diagram of a database query using gRPC — Controlling a database query via Protocol Buffers (.proto file)

HTTP/2: High-performance streaming

HTTP/2 plays a central role in gRPC because it enables the transport of compact binary data in addition to the highly efficient exchange of messages and data. The network protocol provides four methods for remote procedure calls:

1. Unary RPCs are the simplest gRPC method. The client sends an individual request to the server. Just like a normal function call, the client then gets an individual response back.

Example: rpc SayHello (HelloRequest) returns (HelloResponse)

2. With server streaming RPCs, more complex message exchange is possible within a single RPC call. First, the client sends a request to the server. Then it receives a stream from the server with a more extensive message sequence (efficient message ordering within an individual RPC call). The client then reads from this stream until there are no more messages.

Example: rpc LotsOfReplies (HelloRequest) returns (stream HelloResponse)

3. A client streaming RPC reverses this process: The client writes a series of messages and then streams them to the server. Once the client writes the messages, it waits for the server to read them and return the response. Once again, message ordering takes place within an individual RPC call.

Example: rpc LotsOfGreetings (stream HelloRequest) returns (HelloResponse)

4. Bi-directional streaming RPCs are the most complex form of communication, in which both sides send a sequence of messages. Both data streams operate independently, allowing the client and server to read and write in any order. For example, the server could wait to receive all the client’s messages before writing its responses. Or it could alternately read a message, then write a message. Other combination of reads and writes are also possible.

Example: rpc BidiHello (stream HelloRequest) returns (stream HelloResponse)

Methods 2 to 4 use nested requests to establish highly efficient multiplexing, where multiple signals can be bundled within a single TCP connection and transmitted simultaneously over the network. The powerful HTTP/2 protocol eliminates data traffic blocking.

Diagram of streaming with HTTP/2 — Streaming methods with HTTP/2

Pros and cons of gRPC

gRPC has many advantages. The framework is relatively easy to implement because it uses a simple and fairly easy-to-learn IDL for creating .proto files. That way you can easily upgrade older programs with a powerful gRPC interface to transfer large files much faster.

In addition, gRPC has been widely tested and is highly scalable, which means you can use it for even more complex and extensive communications, such as in globally connected client-server architectures. At the same time, HTTP/2 boosts efficiency not only through multiplexing and bidirectional streaming. It also enables header compression, which significantly reduces the data volume of requests and responses in the network.

The multi-layered and highly standardized design of the gRPC framework reduces programming effort. This way, developers can focus primarily on implementing the methods. If the framework requires modifications, programmers and system developers benefit from freely accessible source code.

Furthermore, Protocol Buffers and the associated Protobuf compilers enable cross-platform communication: Different operating systems, disparate components in client-server architectures and different programming languages no longer present an obstacle. For example, software written in C can communicate with Java software. Protobuf compilers are now available for many other languages, such as C#, C++, Go, Objective-C, Java, Python, Node.js, Android Java, Swift, Ruby, and PHP.

Flexibility is another advantage of gRPC. For example, you can use it for exchanging data between microservices or it can be used by mobile apps that share their data with servers. Another advantage: The protocol allows you to implement the latest security technologies. gRPC has built-in authentication and promotes the use of SSL/TLS to authenticate and encrypt communication.

Weaknesses of gRPC: Testing of gRPC interfaces is inadequate at this stage of development. gRPC messages encoded with protobuf are not human-readable. When analyzing traffic, and especially during debugging, you have to use additional instances to convert the code into an understandable form and locate sources of error. Further drawbacks arise when you connect distributed client-server architectures. gRPC links remote computers and is therefore more vulnerable than local systems. gRPC requires a stable and powerful network. The network, data traffic, transmission protocols as well as the client and server should never be weak points that hackers can exploit for attacks. Another drawback is that gRPC doesn’t support multicasting.

Comparison of gRPC and REST

Thanks to its positive features, gRPC is a viable alternative to REST (Representational State Transfer). REST is excellent for simple services, while gRPC is ideal for more complex interfaces (APIs) and services. REST typically uses the JSON data format for exchanging data between applications. JSON is text-based and strains network resources.

By contrast, gRPC can organize a much more compact stream using Protocol Buffers and HTTP/2. Compared to JSON, gRPC reduces memory requirements by nearly 70 percent through binary serialization of data. In addition, bidirectional streaming, which works without blocking data interchange, offers significant performance and speed advantages over REST.

Currently, compatibility with web apps is inadequate because these apps often aren’t optimized for the use of protocol buffers, the “contract-first approach” of gRPC and the contract- first APIs of the gRPC framework. The disadvantage of working with web applications is that no gRPC service can be accessed directly from a browser at this time. This isn’t a problem with REST because the conventional HTTP protocol is supported by all browsers, unlike the more recent HTTP/2. However, it’s relatively easy to overcome this shortcoming so that the same service can be used for a web application and a mobile app. One option for web applications is gRPC-Web. gRPC developers are still working on other solutions to make it as easy as possible for gRPC and web-based tools to work together.

Where is gRPC used?

gRPC is ideal for efficient inter-process communication in distributed client-server architectures with an emphasis on low latency and high data and message throughput. gRPC is often used to connect services or microservices within and between remote data centers. gRPC tools are commonly used in multilingual environments because they support most popular development languages.

Speed, efficiency and multilingual capability make gRPC especially suitable for mobile applications and app communications. gRPC is increasingly used to control the final leg of distributed computing networks by connecting devices, mobile applications, and browsers to back-end services.

Furthermore, powerful streaming via HTTP/2 makes gRPC ideal for point-to-point real-time communication. The Internet of Things (smart home technologies) benefits from this resource-friendly system, which is increasingly used to regulate communication between low-resource clients. Thanks to performance advantages and easy development, this communications technology could play a key role in future cloud applications and diminish the dominance of REST. gRPC is also currently being marketed as an alternative to XML (Extensible Markup Language).

Note

XML is a commonly used format for data exchange and structured storage of information.