XenonStack Recommends

gRPC Adoption and Working Architecture

Acknowledging Data Management
          Best Practices with DataOps

Subscription

XenonStack White Arrow Image

What is gRPC?

gRPC is a high-performance, open-source universal RPC framework. In simple words, it enables the server and client applications to communicate transparently and build connected systems. GRPC is developed and open-sourced by Google.

What is RPC?

The remote procedure call is quite an interesting concept. Remote Procedure Call is a high-level model for client-server communication. Assume there are two computers, computer A(on local) and computer B(on some network). Computer B provides some APIs. Let’s say it has some procedures which can be run, and these procedures can be run on computer B itself.

How GRPC Works?

  • A client application can call methods directly on a server-side application present on other machines.
  • Service is defined, methods are specified, which can be further remotely called with their parameters and return types.
  • On the other hand, the server runs a GRPC server to handle client calls.
  • It uses protocol buffers as the Interface Definition Language to enable communication between two systems used to describe the service interface and the structure of payload messages.
  • HTTP/2 - GRPC is basically a protocol built on top of HTTP/2. HTTP/2 is used as transport.
  • Protobuf serialization - Messages that we serialize both for the request and response are encoded with protocol buffers.
  • Clients open one long-lived connection to the GRPC server.
  • A new HTTP/2 stream for each RPC call.
  • Allows Client-Side and Server-Side Streaming.
  • Bidirectional Streaming.

The rise of containerized applications and microservices is resulting in the evolution of technologies optimized for contemporary workloads. Source: gRPC - The Protocol Of Microservices

Benefits of Adopting GRPC

HTTP/REST Features

  • Easy to understand.
  • Web infrastructure already built on top of HTTP.
  • Great tooling for testing, inspection, and modification.
  • Loose coupling between clients/servers makes changes easy.
  • High-quality HTTP implementations in every language.

Issues with Rest APIs?

  • No formal (machine-readable) API contract.
  • Streaming is difficult (impossible in some languages).
  • Bi-directional streaming isn’t possible at all.
  • Inefficient (textual representations aren’t optimal for networks).

Guide to Differentiating GRPC VS REST

Payload Format

  • Payload Format is one of the major differences between GRPC and REST. In most cases, REST messages contain JSON. Theoretically can send anything as a response, but practically for the REST system, the best practice is JSON.
  • But on the other hand, GRPC is all about Protobuf messages. Protobuf is the best way of encoding structured data.
  • It is much more efficient than JSON and more compressed.
  • On the other hand, JSON is the textual format.

Transfer Protocols

  • Rest is heavily dependent on HTTP 1.1, and on the other hand, GRPC is based on HTTP/2. HTTP 2 is Binary protocol, and HTTP 1.1 is Textual. Binary protocol is much efficient to parse, and it's safe.
  • HTTP 2 is multiplexing in nature. It overcomes the Head-of-Line Blocking problem. In HTTP 1.1, where there is many request P Client, then serve each request one by one. Due to which slow request slows down all the other subsequent request. But HTTP 2 has the capability of serving multiple requests and responses at the same time called MultiPlexing.
  • HTTP 2 uses header compression to reduce overhead (resolved excess time and memory problem).
  • HTTP 2 also enables Duplex Streaming. In other words, HTTP 2 allows reading and writing simultaneously, without requiring line turnarounds. Reading and writing events are independent of each other.

Streaming Vs. Request/Response

  • When talking about REST, it uses the request-response model. On the other hand, GRPC is taking the full advantages of HTTP 2 and allows us to stream the information constantly in various streaming options provided by HTTP 2.
  • Server Streaming - In this type of streaming, the Server delivers the client's content or information, either live or on-demand.
  • Client Streaming - In Client streaming, let's say an example, a client writes a sequence of messages and, after that, sends them to the server as a stream. And then, the client will wait for the server to read them and return the response.
  • Bidirectional Streaming - This type of streaming initiated by the client, and further, there are two cases, either the server has to wait till all the client’s messages have been received on the client-side or the server and client starts doing ping-pong to each other, which means both server and client both able to communicate another hand independently in a full-duplex fashion.

Click to explore Cloud-Native Databases on Docker and Kubernetes

Why GRPC Matters?

  • Ability to break free from the call-and-response architecture. GRPC is built on HTTP/2, which supports the traditional Request/Response model and bidirectional streams.
  • Switch from JSON to protocol buffers.
  • Multiplexing.
  • Duplex Streaming.
  • Because of the binary data format, it gets much lighter.
  • Polyglot.

How to Adopt GRPC?

When talking about Microservices, previously in REST, all the services have interconnection through REST APIs. One service calls either one service or two services or maybe more services, and further those services may be calling other services. If any of the services is slow, it will affect all the system because REST does not support such features as multiplexing, duplex streaming, and REST APIs to communicate with each other with payloads like JSON, XML, and many more. But practically, they have to communicate through JSON payloads which makes the process very slow, takes more memory, and can’t compress. GRPC overcomes all these issues. But use GRPC only in those use cases where there is internal communication between services. Multiplexing, full-duplex, proto request/response make GRPC much faster as compared to REST. GRPC is only available for internal services because there are no APIs available for external use. Still, the Google team is working on GRPC-web to also use this for external services communications. The second option is to create one Microservice using REST which can deal with UI/ Externally, and the rest of the services are dealing with each other internally through GRPC. GRPC is used in those use cases where there is a requirement of communication between services internally.
Click to explore Why Cloud-Native Applications?

What are the Best Practises of GRPC?

Below are the best practices of GRPC.

GRPC in Production

Many companies like Netflix, Cisco, Wisconsin, Cockroach Labs, and many more started using GRPC to connect multiple services in the environment. Typical use cases are -
  • Multi-language communications with idiomatic APIs.
  • Large-scale Microservice communication.
  • Highly efficient communication for Cloud services (e.g., storage, messaging, and many more).
  • Device-to-Device and Device-to-Cloud for embedded systems.
  • Unified IPC and remote communication.

WebSocket v/s GRPC

It’s not about WebSocket v/s GRPC. GRPC uses HTTP/2 compared with WebSockets. WebSocket is a protocol beneficial for creating a two-way channel between a server and web browser. Websockets overcomes all the issues with HTTP such as - To create the WebSocket connection, the client has to send the WebSocket handshake request, and then the server sends the WebSocket handshake response. But later on, this limitation is overcome by HTTP/2 by introducing server push communication. Now in HTTP/2, Server Push allows the server to send the resources to the client, but this client has to stay on the connection to get the updates.

HTTP/2 against WebSocket

HTTP/2 WebSocket
Headers Compressed No
Binary Yes Binary or Textual
Client/Server + Server Direction Push Bidirectional
Full Duplex Yes Yes
Multiplexing Yes Yes

Is HTTP/2 is a replacement for WebSocket?

In simple words, NO. HTTP/2 introduces Server Push, which allows the server to send the resources to the client, server push processed by the browser means to say it is only used to improve the client's resource loading from the browser, cannot apply in the application code. But on the other hand, in WebSocket, developers are allowed to use API, responsible for consuming and pushing the messages with a full-duplex connection. Another reason is that if the connection is closed between the content pushing process and the connection is opened again, this connection cannot continue from where it left. Some browsers don’t support Server Push.
  • The bidirectional protocol involves data streaming between client and server(either client or server can send a message). On the other hand, in HTTP, a request is always started by the client, and the server is used to process the response (unidirectional protocol). The client (browsers) can only request information from servers; servers cannot push the data to the client when it wants to. But data can push to the client in Real-Time on-demand with the help of WebSockets.

Conclusion

gRPC is a powerful and open-source universal RPC framework for working with Remote Procedure Calls. It enables the client and server applications to communicate transparently and build connected systems. The RPCs allow users to write code that will run on a local computer and even be executed on another computer.

Related blogs and Articles

Overview of The New Component-Driven Responsive Design

Enterprise Digital Platform

Overview of The New Component-Driven Responsive Design

Introduction Responsive Design Today, when we talked about the term: "responsive design," the first thought that came to our mind was using media queries to change layout when resizing a design from desktop size to tablet size to mobile size. But shortly, this insight of responsive design could also be considered outdated using tables for page layout.