Complete Guide to GRPC Adoption and Working Architecture
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 API’s, 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 is able to 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 different systems used for describing 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 a 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 GRPC server.
- A new HTTP/2 stream for each RPC call.
- Allows Client-Side and Server-Side Streaming.
- Bidirectional Streaming.
Benefits of Adopting GRPC
- Easy to understand.
- Web infrastructure already built on top of HTTP.
- Great tooling for testing, inspection, and modification.
- Loose coupling between clients/server 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 is one of the major difference between GRPC and REST. In most of the 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.
- Rest is heavily dependent on HTTP 1.1, and on the other hand, GRPC based on HTTP/2. HTTP 2 is Binary protocol, and HTTP 1.1 is Textual. Binary protocol is much efficient to parse and its 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 each request are served one by one. Due to which slow request slows down all the other subsequent request. But HTTP 2 has the capability of serving the multiple request and response 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 but 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, Server delivers the content or information to the client 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 send 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 has been received on the client side or the server and client starts doing ping-pong to each other, means both server and client both able to communicate another hand independently in a full-duplex fashion.
Why GRPC Matters?
- Ability to break free from the call-and-response architecture. GRPC is built on HTTP/2, which supports traditional Request/Response model and bidirectional streams.
- Switch from JSON to protocol buffers.
- Duplex Streaming.
- Because of binary data format, it gets much lighter.
How to Adopt GRPC?
When talking about Microservices, previously in case of REST, all the services are interconnected 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, then it will affect all the system because REST does not support such features like multiplexing, duplex streaming and REST APIs have 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, also take more memory and can’t be compressed.
But all these issues are overcome by GRPC. But GRPC can be used only in those use cases where there is internal communication between services. Multiplexing, full duplex, proto request/response makes GRPC much faster as compared REST. GRPC is only available for internal services because there is no APIs available for external use, but the Google team is working on GRPC-web also so that users can also use this for external services communications.
Second option is to create one Microservice using REST which can deal with UI/ Externally and rest of services are dealing with each other internally through GRPC. GRPC used in those use cases where there is a requirement of communication between services internally.
Best Practises of GRPC
GRPC in Production
Many of the companies like Netflix, Cisco, Wisconsin, Cockroach labs and many more started using GRPC for connecting 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 used 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 for this client have to stay on the connection to get the updates.
HTTP/2 against WebSocket
|Binary||Yes||Binary or Textual|
|Client/Server + Server||Direction Push||Bidirectional|
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 resource loading by the client from the browser, cannot apply in the application code. But on the other hand, in WebSocket, developers are allowed to use API which is responsible for consuming and pushing the messages with a full duplex connection. Another reason is that if the connection closed in between the content pushing process, and further the connection is opened again, then this connection cannot continue from where it left. Some browsers don’t support Server Push.
- Bidirectional protocol - It involves streaming of data between client and server(either client or server can send a message) but on the other hand in HTTP, a request is always started by the client and the the server used for processing the response (unidirectional protocol). The client (browsers) can only request information from servers; servers not allowed to push the data to the client when it wants to. But with the help of WebSockets, data can be pushed to the client in Real-Time on demand.