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. It 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.The rise of containerized applications and microservices is resulting in the evolution of technologies optimized for contemporary workloads. Source: gRPC - The Protocol Of Microservices
How it 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 - it 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 its server.
- A new HTTP/2 stream for each RPC call.
- Allows Client-Side and Server-Side Streaming.
- Bidirectional Streaming.
What are the benefits of adopting it?
The benefits of adopting gRPC are listed below:
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).
A Cloud-Native database is a sort of database service which is used to build, deployed and delivered through cloud platforms. Click to explore about, Cloud Native Databases on Docker and Kubernetes
Guide to Differentiating gRPC VS REST
The difference between gRPC and REST is described below:
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, it 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, it 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, it 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.
Applications that are developed and deployed using cloud-based technologies are known as Cloud-Native Applications. Click to explore about, Why Cloud Native Applications?
Why it is important?
- Ability to break free from the call-and-response architecture. It 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 it?
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. It overcomes all these issues.
But use it only in those use cases where there is internal communication between services. Multiplexing, full-duplex, proto request/response make it much faster as compared to REST. It 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 it. It is used in those use cases where there is a requirement of communication between services internally.
An approach to develop, build and ship applications that takes the advantages of modern Cloud computing services. Click to explore about, Architect and Design Cloud-Native Applications
What are the Best Practises?
Below are the best practices of gRPC.gRPC in Production
Many companies like Netflix, Cisco, Wisconsin, Cockroach Labs, and many more started using it 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. It 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.
- Click to know about Cloud-Native Application Development Services
- Read more about Microservices with Java and Golang
