Network tech­nol­o­gy 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­men­tal 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­ni­ca­tion in dis­trib­uted client-server ar­chi­tec­tures extremely ef­fi­cient­ly using in­no­v­a­tive methods. Like its pre­de­ces­sor RPC, it works at the process level. A key feature of inter-process com­mu­ni­ca­tion using gRPC is the trans­paren­cy principle: Remote instances interact so closely and smoothly, even at great distances, that their com­mu­ni­ca­tion appears identical to local com­mu­ni­ca­tion between internal machine processes.

gRPC was initially developed by Google in 2015. Today, the Cloud Native Computing Foun­da­tion is in charge of dis­trib­ut­ing and de­vel­op­ing the com­mu­ni­ca­tion tech­nol­o­gy. gRPC is open source, meaning the source code is publicly ac­ces­si­ble. 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­cess­ing the data. Protocol buffers are saved as simple text files with the extension .proto.

gRPC is fre­quent­ly referred to as a framework. One useful feature of a framework is that it provides de­vel­op­ers with a standard pro­gram­ming structure, saving time and effort. For example, the stan­dard­ized 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 stan­dard­ized 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 de­f­i­n­i­tion language (IDL) and describe an interface in a language-in­de­pen­dent 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 pa­ra­me­ters that are sent with a request and the type of return value that can be expected.

From the remote per­spec­tive, 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, prepa­ra­tions are needed before the search can be completed. On the server side, a service and a gRPC server are im­ple­ment­ed based on protocol buffers. The re­quest­ing client generates a matching stub. If the stub is available, the client ap­pli­ca­tion calls the cor­re­spond­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­pli­ca­tions are sometimes written in different pro­gram­ming languages. gRPC overcomes these lim­i­ta­tions through special in­ter­faces and trans­la­tion mech­a­nisms.

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 se­ri­al­iza­tion (mar­shalling), a standard process in remote procedure calls. The trans­mit­ted data is also de­se­ri­al­ized (un­mar­shalling) so that the com­plete­ly 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. De­f­i­n­i­tion of the service contract for inter-process com­mu­ni­ca­tion: The services to be set up as well as basic pa­ra­me­ters 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­men­ta­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­ce­dures that are imported at the beginning. These libraries ensure that in­com­pat­i­ble in­ter­faces can com­mu­ni­cate 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 de­f­i­n­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­trol­ling a database query via Protocol Buffers (.proto file)

HTTP/2: High-per­for­mance 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­vid­ual request to the server. Just like a normal function call, the client then gets an in­di­vid­ual 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­vid­ual RPC call). The client then reads from this stream until there are no more messages.

Example: rpc Lot­sOfReplies (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­vid­ual RPC call.

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

4. Bi-di­rec­tion­al streaming RPCs are the most complex form of com­mu­ni­ca­tion, in which both sides send a sequence of messages. Both data streams operate in­de­pen­dent­ly, 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­ter­nate­ly read a message, then write a message. Other com­bi­na­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 si­mul­ta­ne­ous­ly over the network. The powerful HTTP/2 protocol elim­i­nates data traffic blocking.

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

Pros and cons of gRPC

gRPC has many ad­van­tages. The framework is rel­a­tive­ly 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­ni­ca­tions, such as in globally connected client-server ar­chi­tec­tures. At the same time, HTTP/2 boosts ef­fi­cien­cy not only through mul­ti­plex­ing and bidi­rec­tion­al streaming. It also enables header com­pres­sion, which sig­nif­i­cant­ly reduces the data volume of requests and responses in the network.

The multi-layered and highly stan­dard­ized design of the gRPC framework reduces pro­gram­ming effort. This way, de­vel­op­ers can focus primarily on im­ple­ment­ing the methods. If the framework requires mod­i­fi­ca­tions, pro­gram­mers and system de­vel­op­ers benefit from freely ac­ces­si­ble source code.

Fur­ther­more, Protocol Buffers and the as­so­ci­at­ed Protobuf compilers enable cross-platform com­mu­ni­ca­tion: Different operating systems, disparate com­po­nents 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­ni­cate 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­i­bil­i­ty is another advantage of gRPC. For example, you can use it for ex­chang­ing data between mi­croser­vices 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­nolo­gies. gRPC has built-in au­then­ti­ca­tion and promotes the use of SSL/TLS to au­then­ti­cate and encrypt com­mu­ni­ca­tion.

Weak­ness­es of gRPC: Testing of gRPC in­ter­faces is in­ad­e­quate at this stage of de­vel­op­ment. gRPC messages encoded with protobuf are not human-readable. When analyzing traffic, and es­pe­cial­ly 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­a­ble 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­ti­cas­t­ing.

Com­par­i­son of gRPC and REST

Thanks to its positive features, gRPC is a viable al­ter­na­tive to REST (Rep­re­sen­ta­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­chang­ing data between ap­pli­ca­tions. 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 re­quire­ments by nearly 70 percent through binary se­ri­al­iza­tion of data. In addition, bidi­rec­tion­al streaming, which works without blocking data in­ter­change, offers sig­nif­i­cant per­for­mance and speed ad­van­tages over REST.

Currently, com­pat­i­bil­i­ty with web apps is in­ad­e­quate 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 dis­ad­van­tage of working with web ap­pli­ca­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 rel­a­tive­ly easy to overcome this short­com­ing so that the same service can be used for a web ap­pli­ca­tion and a mobile app. One option for web ap­pli­ca­tions is gRPC-Web. gRPC de­vel­op­ers 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­ni­ca­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­croser­vices within and between remote data centers. gRPC tools are commonly used in mul­ti­lin­gual en­vi­ron­ments because they support most popular de­vel­op­ment languages.

Speed, ef­fi­cien­cy and mul­ti­lin­gual ca­pa­bil­i­ty make gRPC es­pe­cial­ly suitable for mobile ap­pli­ca­tions and app com­mu­ni­ca­tions. gRPC is in­creas­ing­ly used to control the final leg of dis­trib­uted computing networks by con­nect­ing devices, mobile ap­pli­ca­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­ni­ca­tion. The Internet of Things (smart home tech­nolo­gies) benefits from this resource-friendly system, which is in­creas­ing­ly used to regulate com­mu­ni­ca­tion between low-resource clients. Thanks to per­for­mance ad­van­tages and easy de­vel­op­ment, this com­mu­ni­ca­tions tech­nol­o­gy could play a key role in future cloud ap­pli­ca­tions and diminish the dominance of REST. gRPC is also currently being marketed as an al­ter­na­tive to XML (Ex­ten­si­ble Markup Language).

Note

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

Go to Main Menu