Why gRPC for Inter-Microservice Communication

Hi folks! In this blog, we will understand why one should use gRPC for inter-service communication over other RESTful services.

What is gRPC?

It 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. Google developed gRPC and made it available open-source. With it, a customer can directly call methods on a server application on a different machine as if it were a local object. gRPC is based on the foundations of conventional Remote Procedure Call (RPC) technology but implemented on top of the modern technology stacks such as HTTP2, protocol buffers, etc., to ensure maximum interoperability.

How gRPC Communicates Between Services

When the client invokes the service, the client-side gRPC library uses the protocol buffer and marshals the remote procedure call, which is then sent over HTTP2. The server un-marshals the request and executes the respective procedure invocation using protocol buffers. The response follows a similar execution flow from the server to the client.

The main advantage of developing services and clients with gRPC is that your service code or client-side code doesn’t need to worry about parsing JSON or similar text-based message formats (within the code or implicitly inside the underlying libraries such as Jackson, which is hidden from service code). What comes in the wire is a binary format, which is unmarshalled into an object. Also, having first-class support for defining a service interface via an IDL is a powerful feature when we have to deal with multiple microservices and ensure and maintain interoperability.

Why gRPC Is So Effective

• It has the 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.
• It can switch from JSON to protocol buffers.
• Multiplexing.
• Duplex streaming.
• Because of the binary data format, it is very light.
• Polyglot.

When to Use gRPC

Initially, all microservices were 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 are slow, then it will affect all the systems because REST does not support features like multiplexing or duplex streaming. REST APIs communicate with each other with payloads like JSON, XML, and many more. This makes the process very slow, memory-consuming, and non-compressible.

gRPC has resolved all these issues. But it can be used only in those use cases where there is internal communication between services. Multiplexing, full-duplex, and proto request/responses make gRPC much faster as compared to REST. It is only available for internal services because there are no APIs available for external use, but the Google team is working on gRPC-web too so that users can also use this for external services communications.

The second option is to create one microservice using REST which can deal with external services and the rest of the services deal with each other internally through gRPC. It is used in those use cases where there is a requirement of communication between services internally. Therefore, as a general practice, we can use it for all synchronous communications between internal microservices. Other synchronous messaging technologies such as RESTful services and GraphQL are more suitable for external-facing services.

Conclusion

To conclude, APIs created with gRPC gives us incredible performance improvement as compared to legacy REST API. Our response time reduces from 15 ms to 1.71 ms for each request, where average requests range from 600 rpm to 1700 rpm.

Further Reading

RPC With Redis-Based Java Remote Services