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 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 communicate 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. Server un-marshal 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?
- 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.
- Multiplexing.
- Duplex Streaming.
- Because of binary data format, it gets much lighter.
- Polyglot.
When to use gRPC?
Initially, all micro-services 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 is slow, then it will affect all the system because REST does not support features like multiplexing, 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, proto request/response makes gRPC much faster as compared to REST. It 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 external services and rest of services deal with each other internally through gRPC. It 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 ranges from 600 rpm to 1700 rpm.
