Network tech­no­logy is rapidly advancing on a constant basis. To meet the in­creas­ing demands of dis­trib­uted computer systems, a new system called gRPC was developed for remote procedure calls. The "g" stands for Google, which was in­stru­ment­al in the de­vel­op­ment of gRPC. We’ll explain what gRPC is, how it works, and where it is used.

What is gRPC?

gRPC is a modern remote procedure call system that handles com­mu­nic­a­tion in dis­trib­uted client-server ar­chi­tec­tures extremely ef­fi­ciently using in­nov­at­ive methods. Like its pre­de­cessor RPC, it works at the process level. A key feature of inter-process com­mu­nic­a­tion using gRPC is the trans­par­ency principle: Remote instances interact so closely and smoothly, even at great distances, that their com­mu­nic­a­tion appears identical to local com­mu­nic­a­tion between internal machine processes.

gRPC was initially developed by Google in 2015. Today, the Cloud Native Computing Found­a­tion is in charge of dis­trib­ut­ing and de­vel­op­ing the com­mu­nic­a­tion tech­no­logy. gRPC is open source, meaning the source code is publicly ac­cess­ible. Third parties are permitted and en­cour­aged to make changes and en­hance­ments to the code.

By default, gRPC uses HTTP/2 for trans­port­ing data streams between remote computers. Protocol buffers developed by Google are used for pro­cessing the data. Protocol buffers are saved as simple text files with the extension .proto.

gRPC is fre­quently referred to as a framework. One useful feature of a framework is that it provides de­velopers with a standard pro­gram­ming structure, saving time and effort. For example, the stand­ard­ised framework of gRPC includes a variety of functions and elements that don’t have to be pro­grammed from scratch every time. The gRPC framework also defines stand­ard­ised in­ter­faces to specific sources (such as databases).

How gRPC works: mul­ti­lin­gual and efficient thanks to protocol buffers and HTTP/2

Protocol buffers (Protobuf) perform several functions in the gRPC system. They serve as an interface defin­i­tion language (IDL) and describe an interface in a language-in­de­pend­ent way. That means they aren’t bound to a specific pro­gram­ming 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 para­met­ers that are sent with a request and the type of return value that can be expected.

From the remote per­spect­ive, protocol buffers serve as the un­der­ly­ing message exchange format that defines message struc­tures, types, and objects. They ensure that the client and server "un­der­stand" each other and operate as an optimally efficient func­tion­al 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, pre­par­a­tions are needed before the search can be completed. On the server side, a service and a gRPC server are im­ple­men­ted based on protocol buffers. The re­quest­ing client generates a matching stub. If the stub is available, the client ap­plic­a­tion calls the cor­res­pond­ing 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 re­quest­ing instance (for example, "Number of items found").

Client- and server-side ap­plic­a­tions are sometimes written in different pro­gram­ming languages. gRPC overcomes these lim­it­a­tions through special in­ter­faces and trans­la­tion mech­an­isms.

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 seri­al­isa­tion (mar­shalling), a standard process in remote procedure calls. The trans­mit­ted data is also deseri­al­ised (un­mar­shalling) so that the com­pletely abstract data struc­tures can be processed by the client and server in later steps.

Image: Diagram of message exchange using gRPC in a client-server architecture
Message exchange via gRPC in a client-server ar­chi­tec­ture

gRPC workflow and first steps via protocol buffers

A typical gRPC workflow is divided into four steps:

  1. Defin­i­tion of the service contract for inter-process com­mu­nic­a­tion: The services to be set up as well as basic para­met­ers and return types that can be called remotely are defined.
  2. Gen­er­a­tion 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 ap­pro­pri­ate classes for the desired target language (such as C++ or Java).
  3. Im­ple­ment­a­tion of the server in the chosen language.
  4. Creation of the client stub that calls the service. The request(s) are then handled by the server and client(s).
Image: 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-pro­grammed trans­la­tion pro­ced­ures that are imported at the beginning. These libraries ensure that in­com­pat­ible in­ter­faces can com­mu­nic­ate with each other in mul­ti­lin­gual and disparate client-server ar­chi­tec­tures. For example, you use these wrappers to generate the classes necessary for reading and writing messages.

The following diagram shows how the service defin­i­tion (inventory.proto) controls the query of a database in a client-server ar­chi­tec­ture:

Image: Diagram of a database query using gRPC
Con­trolling a database query via Protocol Buffers (.proto file)

HTTP/2: High-per­form­ance 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 in­di­vidu­al request to the server. Just like a normal function call, the client then gets an in­di­vidu­al response back.

Example: rpc SayHello (Hel­loRe­quest) returns (Hel­loRe­sponse)

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 in­di­vidu­al RPC call). The client then reads from this stream until there are no more messages.

Example: rpc Lot­sO­fReplies (Hel­loRe­quest) returns (stream Hel­loRe­sponse)

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 in­di­vidu­al RPC call.

Example: rpc Lot­sOf­Greet­ings (stream Hel­loRe­quest) returns (Hel­loRe­sponse)

4. Bi-dir­ec­tion­al streaming RPCs are the most complex form of com­mu­nic­a­tion, in which both sides send a sequence of messages. Both data streams operate in­de­pend­ently, 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 al­tern­ately read a message, then write a message. Other com­bin­a­tion of reads and writes are also possible.

Example: rpc BidiHello (stream Hel­loRe­quest) returns (stream Hel­loRe­sponse)

Methods 2 to 4 use nested requests to establish highly efficient mul­ti­plex­ing, where multiple signals can be bundled within a single TCP con­nec­tion and trans­mit­ted sim­ul­tan­eously over the network. The powerful HTTP/2 protocol elim­in­ates data traffic blocking.

Image: Diagram of streaming with HTTP/2
Streaming methods with HTTP/2

Pros and cons of gRPC

gRPC has many ad­vant­ages. The framework is re­l­at­ively 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 com­mu­nic­a­tions, such as in globally connected client-server ar­chi­tec­tures. At the same time, HTTP/2 boosts ef­fi­ciency not only through mul­ti­plex­ing and bi­d­irec­tion­al streaming. It also enables header com­pres­sion, which sig­ni­fic­antly reduces the data volume of requests and responses in the network.

The multi-layered and highly stand­ard­ised design of the gRPC framework reduces pro­gram­ming effort. This way, de­velopers can focus primarily on im­ple­ment­ing the methods. If the framework requires modi­fic­a­tions, pro­gram­mers and system de­velopers benefit from freely ac­cess­ible source code.

Fur­ther­more, Protocol Buffers and the as­so­ci­ated Protobuf compilers enable cross-platform com­mu­nic­a­tion: Different operating systems, disparate com­pon­ents in client-server ar­chi­tec­tures and different pro­gram­ming languages no longer present an obstacle. For example, software written in C can com­mu­nic­ate 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.

Flex­ib­il­ity is another advantage of gRPC. For example, you can use it for ex­chan­ging data between mi­croservices 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 tech­no­lo­gies. gRPC has built-in au­then­tic­a­tion and promotes the use of SSL/TLS to au­then­tic­ate and encrypt com­mu­nic­a­tion.

Weak­nesses of gRPC: Testing of gRPC in­ter­faces is in­ad­equate at this stage of de­vel­op­ment. gRPC messages encoded with protobuf are not human-readable. When analysing traffic, and es­pe­cially during debugging, you have to use ad­di­tion­al instances to convert the code into an un­der­stand­able form and locate sources of error. Further drawbacks arise when you connect dis­trib­uted client-server ar­chi­tec­tures. gRPC links remote computers and is therefore more vul­ner­able than local systems. gRPC requires a stable and powerful network. The network, data traffic, trans­mis­sion 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 mul­tic­ast­ing.

Com­par­is­on of gRPC and REST

Thanks to its positive features, gRPC is a viable al­tern­at­ive to REST (Rep­res­ent­a­tion­al State Transfer). REST is excellent for simple services, while gRPC is ideal for more complex in­ter­faces (APIs) and services. REST typically uses the JSON data format for ex­chan­ging data between ap­plic­a­tions. JSON is text-based and strains network resources.

By contrast, gRPC can organise a much more compact stream using Protocol Buffers and HTTP/2. Compared to JSON, gRPC reduces memory re­quire­ments by nearly 70 percent through binary seri­al­isa­tion of data. In addition, bi­d­irec­tion­al streaming, which works without blocking data in­ter­change, offers sig­ni­fic­ant per­form­ance and speed ad­vant­ages over REST.

Currently, com­pat­ib­il­ity with web apps is in­ad­equate because these apps often aren’t optimised for the use of protocol buffers, the “contract-first approach” of gRPC and the contract- first APIs of the gRPC framework. The dis­ad­vant­age of working with web ap­plic­a­tions is that no gRPC service can be accessed directly from a browser at this time. This isn’t a problem with REST because the con­ven­tion­al HTTP protocol is supported by all browsers, unlike the more recent HTTP/2. However, it’s re­l­at­ively easy to overcome this short­com­ing so that the same service can be used for a web ap­plic­a­tion and a mobile app. One option for web ap­plic­a­tions is gRPC-Web. gRPC de­velopers 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 com­mu­nic­a­tion in dis­trib­uted client-server ar­chi­tec­tures with an emphasis on low latency and high data and message through­put. gRPC is often used to connect services or mi­croservices within and between remote data centres. gRPC tools are commonly used in mul­ti­lin­gual en­vir­on­ments because they support most popular de­vel­op­ment languages.

Speed, ef­fi­ciency and mul­ti­lin­gual cap­ab­il­ity make gRPC es­pe­cially suitable for mobile ap­plic­a­tions and app com­mu­nic­a­tions. gRPC is in­creas­ingly used to control the final leg of dis­trib­uted computing networks by con­nect­ing devices, mobile ap­plic­a­tions, and browsers to back-end services.

Fur­ther­more, powerful streaming via HTTP/2 makes gRPC ideal for point-to-point real-time com­mu­nic­a­tion. The Internet of Things (smart home tech­no­lo­gies) benefits from this resource-friendly system, which is in­creas­ingly used to regulate com­mu­nic­a­tion between low-resource clients. Thanks to per­form­ance ad­vant­ages and easy de­vel­op­ment, this com­mu­nic­a­tions tech­no­logy could play a key role in future cloud ap­plic­a­tions and diminish the dominance of REST. gRPC is also currently being marketed as an al­tern­at­ive to XML (Ex­tens­ible Markup Language).

Note

XML is a commonly used format for data exchange and struc­tured storage of in­form­a­tion.

Go to Main Menu