gRPC (Google Remote Procedure Call) – A Modern Way to Build Scalable and Fast APIs

Microservices gives us a higher level of complexity, and there are several inherent challenges with microservices you need to take into account when changing from a monolithic architecture. Like,

• Inter-service network communication
• Data serialization/de-serialization
• Security/Authentication
• Language Interoperability
• Streaming Data
• Monitoring
• Debugging

And today, we will have a brief about gRPC (Google Remote Procedure Call), which gives us the tools and capabilities to combat these issues without having to roll your custom frameworks.

So what is gRPC (Google Remote Procedure Call)?

gRPC is a modern RPC protocol implemented on top of HTTP/2. HTTP/2 is a Layer 7 (Application layer) protocol, that runs on top of a TCP (Layer 4 – Transport layer) protocol, which runs on top of IP (Layer 3 – Network layer) protocol. gRPC has many advantages over traditional HTTP/REST/JSON mechanism such as

1. Binary protocol (HTTP/2)
2. Multiplexing many requests on one connection (HTTP/2)
3. Header compression (HTTP/2)
4. Strongly typed service and message definition (Protobuf)
5. Idiomatic client/server library implementations in many languages

In addition, gRPC (Google Remote Procedure Call) integrates seamlessly with ecosystem components like service discovery, name resolver, load balancer, tracing and monitoring, among others.

How RPC (Google Remote Procedure Call) works:

Following the numbered arrows in the diagram above:

1. A client application makes a local procedure call to the client stub containing the parameters to be passed on to the server.
2. The client stub serializes the parameters through a process called marshalling.
3. The client stub forwards the request to the local client time library.
4. The local client time library forwards the request to the server stub.
5. The server run-time library receives the request and calls the server stub procedure.
6. The server stub unmarshalls (unpacks) the passed parameters.
7. The server stub calls the actual procedure.
8. The server stub sends back a response to the client-stub in the same fashion.

Connection Options

• Unary RPC: Unary RPCs where the client sends a single request to the server and gets a single response back, just like a normal function call.
• Server Streaming RPC: The client sends a single request to the server and gets a stream to read a sequence of messages back. The client reads from the returned stream until there are no more messages.
• Client Streaming RPC: The client sends a sequence of messages to the server using a provided stream. Once the client has finished writing the messages, it waits for the server to read them and return its response.
• Bidirectional Streaming RPC: Both sides send a sequence of messages using a read-write stream. The two streams operate independently. The order of messages in each stream is preserved.

When to use gRPC (Google Remote Procedure Call)

That said, what are the conditions for using gRPC instead of REST?

• Real-time communication services where you deal with streaming calls
• When efficient communication is a goal
• In multi-language environments
• For internal APIs where you don’t have to force technology choices on clients
• New builds as part of transforming the existing RPC API might not be worth it

You might notice that many of these conditions apply to one specific use case — microservices. After all, there’s a reason Netflix, Lyft, WePay, and more companies operating with microservices have transitioned to gRPC.

Still have questions about gRPC? Contact us now by filling in the form below for a free consultation by one of our senior executives by clicking the button below. We can’t wait to hear from you.