In recent years, Microservices has become a rather familiar concept to software architects and application developers alike. Alongside stable architectures, new technologies and frameworks are constantly being introduced in order to satisfy the many complicating requests from applications. This article will discuss a new technology developed by the Google expert team several years ago.

What is gRPC?

If you had had experience with RPC, then gRPC can be understood as an improved RPC. Similar to RPC, gRPC will provide a means to remotely call and perform a service’s methods at client servers, much like directly performing on those.

On default, gRPC utilizes Protocol Buffers as a language to define services, and as a format for communication between these services.

gRPC allows us to integrate easily the services implemented in different platforms like Java, NodeJS, Go, Python, Ruby…, without having to write intermediary libraries.

What are Protocol Buffers?

Protocol Buffers are a language used to define services, data structure and data type for communication between different services. Each Protocol Buffers definition will be placed in a .proto file.

Let’s check out the following example to have a broader view of Protocol Buffers.

Defining a message structure

In the above code we are defining a message called SearchRequest, with three information fields of the respective formats below:

  • query: a query in string format.
  • page_number: the page number in integer format.
  • result_per_page: the number of records in each page in integer format.

Defining multiple message structures

Each .proto file can contain various different message definitions, and in this example, we are defining the structures for both SearchRequest and SearchResponse in the same file.

Data types with complex structures

Alongside basic data types like byte, integer, and string, Protocol Buffers also support the definition of complex-structured messages, nested messages, enum data types, array data types, and so on.

In this example, we are defining the results of SearchResponse as a Result message data field.

Defining services

To perform a RPC call, we need to have the Server and Client. In the above definition, we want to have a service called SearchService, with one method being to search with SearchRequest as input and SearchResponse as output.

We can also place the definitions for messages and services in the same .proto file.

Generating codes

After defining the data structures and services in the .proto file, we will need to generate codes for classes respective of the programming languages in use like C#, Java, C++…

Google has provided us with a tool for this task called protoc.

Protoc helps us translate the .proto file into respective code files with the below parameters:

  • IMPORT_PATH: a folder that contains the relevant .proto files used during the compilation process.
  • We can also provide other parameters to direct the compilation process:
    • –cpp_out: generates C++ codes to the DST_DIR folder.
    • –java_out: generates Java codes to the DST_DIR folder.
    • –python_out: generates Python codes to the DST_DIR folder.
    • –go_out: generates Go codes to the DST_DIR folder.
    • –ruby_out: generates Ruby codes to the DST_DIR folder.
    • –objc_out: generates Objective-C codes to the DST_DIR folder.
    • –csharp_out: generates C# codes to the DST_DIR folder.
    • –php_out: generates PHP codes to the DST_DIR folder.

More details can be found at

Advantages of Protocol Buffers

When compared with XML, Google finds the below conclusion regarding Protocol Buffers. In particular, it is:

  • Simpler to use.
  • 3 to 10 times smaller.
  • 20 to 100 times faster.
  • Less ambiguous.
  • Generate data access classes that are easier to use programmatically.


So, what is special about gRPC that makes it more effective than RPC? The answer is HTTP/2, or particularly, the fact that gRPC is built based on HTTP/2. The improvements of HTTP/2 compared to its previous versions had allowed for better and more effective http connections. Let’s review some notable features of HTTP/2:

  • Multiplexing: multiplexing is one of the most important features of HTTP/2, with which we can simultaneously send and receive various results in one single connection. See the following illustrations:

HTTP/1.1 requires different connections for different requests.

HTTP/2.0 requires only 1 connection for various requests and responses.

  • Header compression: for every http request, we need to provide necessary information like cookies, agents…. However, repeatedly sending these data can consume a particular amount of resources, and thus reduce the application’s performance. With HTTP/2, it will be optimized by compressing such information and having both the client and server to store data from previous requests, then omit redundant information in the newer ones.
  • Binary data: HTTP/2 transfers data in binary form instead of text form like in previous versions. This helps improve the efficiency of the transfer and avoid common errors in processing request data like blanks, special characters, and so on.

Other improvements will be detail in the reference links at the end of this article.

What types of RPC methods are supported?

gRPC provides us with 4 feasible types of methods.

Unary RPCs

This method is similar to conventional RPCs, where the Client sends a request to the Server, wait for processing, then have the results returned to the Client.

We can define this method in the .proto file as follows:

Server streaming RPCs

In this method, the Client will send a request to the Server, then wait for Server to return a data stream. The client will then read the messages in the stream, until there are no more messages returned. The order of the messages in each stream must be the same between the Client and Server.

We can define this method in the .proto file as follows:

Client streaming RPCs

Similar to Server streaming RPCs, in this type the Client send a request to the Server, which will then read the data stream and perform necessary business logic, then return the data to the Client.

We can define this method in the .proto file as follows:

Bidirectional streaming RPCs

In this method, data will travel bidirectionally from both the Client and Service, with independent flows of data stream, and the Client and Server will process the stream separately. This means that when the Client sends a message to the Server, it can process this message to perform a particular task (while still receiving other messages), and return the results back to the Client (while the Client is still sending other messages).

We can define this method in the .proto file as follows:

Integrating gRPC services in different platforms

As mentioned above, one important improvement of gRPC is its cross-platform support. For simple RPC, it is extremely challenge to integrate the implemented services in different platforms, while gRPC supports this considerably well, without any need for extra libraries. You can create an RPC service at the server side with any programming language (for example, Java), then create a Client to call this RPC service with a completely different language (for example, NodeJS).

For testing, you can download source codes using the links below:

Java is used at Server, with firstName and lastName as input, and the result returned is: “Hello <firstName> <lastName>”

NodeJS is used at Client as follows:

And here we can see the testing result will be:

You can also find sample source codes for gRPC’s other types of methods alongside UnaryRPC in their respective branches:


Other than the aforementioned advantages, you should also consider the following disadvantages when using gRPC:


Tran Huu Lap – FPT Software

FPT TechInsight is now officially introducing the new corner – “READER OPINION”, where you can share your own writings on new technologies, programming experiences, previous projects… to the tech-lover community. Quality posts will be selected to publish on the FPT TechInsight’s website, with attractive royalties sent to the authors, as thanks for their contributions.

We welcome all contributing ideas and writings sent to[email protected]. Please clarify in the email title as “Reader opinion – Full name”. Hotline: +84 853 543 538

Related posts: