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.
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.