gRPC — A recent communication protocol

Over a period of time, people have started to think about work on networking for interconnecting machines; the search for the most optimized remote communication mechanism has started. While different operating systems have internal protocols for remote communication, the challenge is to expose a framework to developers. TCP/IP protocols are considered as the standard cross-platform communication for the networking process and started focusing on, where computers can communicate in the network.

Technologies like CORBA, DCOM, and Java RMI focused on developing a developer-friendly infrastructure. These technologies wanted to try language-agnostic communication which is very important for the client-server architecture.

Then, the evolution of the web, HTTP started to evolve as the standard for communication. HTTP is combined with XML which is a self-descriptive, language-agnostic, and platform-independent framework for remote communication. This resulted in the standardization of SOAP and WSDL, which make sure interoperability with various runtimes and platforms. Then JavaScript and JSON started to become popular. Where APIs played a key role, JSON replaces XML as the preferred wire-format protocol. The combination of HTTP and JSON resulted in a new standard as REST. SOAP used among the large enterprise applications which demand strict attachments with standards and schema definitions, while the contemporary developers used REST.

gRPC and REST:

gRPC stands for Remote Procedure Call, which is an open-source technology used for remote procedure call system.

Google develops gRPC. In some ways, gRPC is like REST which provides a provision to send requests from a client to a server. However, these are different in some ways. The following are points to be considered to understand how REST and gRPC works:

  • Both REST and gRPC are language-agnostic; many tools are available for most of the popular languages
  • gRPC works on the contract bases, to define a contract .proto files are used. This looks similar to Swagger’s swagger.json and to ReFit’s shared interface. With this, any programming language can be generated from those files
  • gRPC uses Protobuf (which is a Protocol Buffer) binary serialization. In this way, it is different from REST, where REST serializes to JSON or XML. The binary serialization is smaller and also faster
  • gRPC used to create enduring connections with the help HTTP/2 protocol. This protocol is simpler and compact, while REST uses HTTP 1.x protocol
  • HTTP 1.1 needs a TCP handshake for each and every request while this causes connection not to be in close state HTTP/2
  • Multiplexed streams are used for HTTP/2 connection. So with a single TCP connection, many streams are possible. These streams are executed in parallel which avoids waiting for each other like in HTTP 1.1
  • gRPC supports bidirectional streaming


From these comparisons and knowledge, we can decide where using gRPC will be an advantage, some examples like in microservices, point-to-point real-time communication, Polyglot, Network constrained environments. Also, we should be clear that gRPC is not an alternate for REST/HTTP APIs, however, it provides an improvement in productivity and also results in performance benefits in specific scenarios, where we can choose gRPC.

Leave a Reply

Your email address will not be published. Required fields are marked *

3 × two =