gRPC Remote Procedure call is a high performance, open-source, feature-rich RPC framework. The ideal usage of gRPC is for inter-service communication in microservices and for communication between mobile applications and servers.
gRPC for mobile applications
Mobile applications can rely on gRPC for improved performance because it’s built over HTTP/2 which has lower latency while providing higher performance for mobile devices that have a slower CPU. Mobile clients can make use of streaming options in gRPC to save bandwidth and reduce the number of TCP connections made to the server which successively helps in reducing CPU usage and help in optimizing battery in mobile devices.
gRPC for microservices
In microservices architecture, inter-service communication should be faster. gRPC uses protocol buffers which are smaller, faster, and can efficiently connect services than JSON. gRPC servers are asynchronous by default which means that they do not block threads on request and can handle multiple requests in parallel. gRPC promotes the use of SSL in which all the data transmitted over the network are encrypted and authentication is integrated.
gRPC APIs using Protobuf
● gRPC uses protocol buffers which are a way of serializing structured data that is strongly typed
● Parsing protocol buffers which are in binary format consume less CPU than parsing JSON which is a text format
● Protocol buffers help in backward compatibility without affecting the client-side code
● A large amount of code can be generated in any language from a simple proto file
Proto file is used to define the messages(request and response), service(RPC endpoint).
The following proto file(cart.proto) is a service contract for a simple cart operation.
he above cart.proto, which contains service and messages which need to be shared between client and server. The API service is to create a cart. The messages can be used for the corresponding request and response defined in the service.
Types of API in gRPC
In gRPC APIs are not CRUD(create/retrieve/update/delete) based, each API can be designed without any constraint. Hence gRPC is not Resource oriented instead of its API specific. We can broadly classify APIs in gRPC into Unary APIs and Streaming APIs
Unary APIs
Unary RPC calls are the simple request-response model in which the client sends a request message and the server responds with a response message. Once the client receives the response, the call is completed. Most of the APIs use Unary RPC models.
Streaming APIs
Streaming RPC calls are available due to the underlying implementation of HTTP/2 in gRPC.
Since multiplexing is supported in HTTP/2, the client and server can push messages in parallel over a single TCP connection which helps in reducing the latency in data transmission.
Three types of Streaming APIs available in gRPC are
● Client Streaming API
● Server Streaming API
● Bidirectional Streaming API
Client Streaming API
In Client streaming RPC calls, the client sends multiple messages to the server and in return, the server sends a single response to the client. Client streaming API can be used when a client needs to send large data to the server without expecting a response from the server. For example, sending data for analytics.
Server Streaming API
In Server streaming RPC calls, the client sends a single message to the server, and in return, the server sends multiple responses to the client. Server streaming API can be used when a server needs to send large data to the client with a single request. For example, sending a live score during a match.
Bidirectional Streaming API
In Bidirectional streaming RPC calls, the client and server send messages to each other asynchronously. Bidirectional API can be used when the client and server don’t wait for each other to send and receive data. For example a chat application.
