Before getting into gRPC, let’s revisit what RPC is.
What is RPC?
Remote Procedure Call(RPC) is a software communication protocol that one program can use to request a service from a program located in another computer on a network without having to understand the network’s details. RPC is used to call other processes on a remote system like a local system. A procedure call is also known as a function call or a subroutine call.
What does RPC do?
The service provider server registers the service with the registry and registers its own metadata such as IP address, port number and method information in the registry. The service consumer Client obtains the service related information through the registry, and then requests the service provider server through the network.
- The client calls the client stub, which is a normal local procedure call with parameters.
- The client stub packs the procedure parameters into a message and makes a system call to send the message. The packing of the procedure parameters is called marshaling.
- The client’s local OS sends the message from the client machine to the remote server machine.
- The server OS passes the incoming packets to the server stub.
- The server stub unpacks the parameters (unmarshalling) from the message.
- When the server procedure is finished, it returns to the server stub, which marshals the return values into a message. The server stub then hands the message to the transport layer.
- The transport layer sends the result message back to the client transport layer, which returns the message back to the client stub.
- The client stub unmarshalls the return parameters and the execution returns to the caller.
What is gRPC?
gRPC is a high-performance, open-source universal RPC framework initially developed by Google in 2015. They even made a github README to list all the meanings of each version of “g”.
Two main characteristics made gRPC become so popular in backend development:
- Adopts HTTP/2. Establishes one connection like a tunnel and sends all responses in one communication
- Uses protocol buffers to define services
First, gRPC builds on HTTP/2’s long-lived connections to create a performant, robust platform for inter-service communication.
HTTP/2 helps gRPC taking the following advantages:
- Multiplexing – Client & Server can push messages in parallel over the same TCP connection, which highly reduces latency verus HTTP/1.1, and improves network utilization.
- Binary Framing – Lighter to transport, safer to decode. Great combination with protocol buffers.
- Server Push – Server can “push” the resources it believes would be required by the client. One client request, multiple server response. Reduce the round-trip latency.
- Header Compression – Less impact on packet size, reduce overhead and improve performance by using HPACK. HTTP/2 maps the header to both client and server sides, which is able to know if the header contains the same value and will only send header value that is different from previous header.
Besides, gRPC uses Protocol Buffers (Protobuf), Google’s mature open source mechanism for serializing structured data. Both protobuf and JSON are for serialization, however, the key difference is that Protobuf is binary data –interchange format, whereas JSON stores data in human-readable text format.Since HTTP/2 relies on the transferred data being binary encoded, protobuf plays a very important role for gRPC.
gRPC introduces three new concepts: channels, remote procedure calls (RPCs), and messages. The relationship among them is that each channel may have many RPCs while each RPC may have many messages. Channels represent virtual connections to an endpoint, which may be backed by many HTTP/2 connections. RPCs are associated with a connection. Messages are associated with RPCs and get sent as HTTP/2 data frames.
To be more specific, messages are layered on top of data frames. A data frame may have many gRPC messages, or if a gRPC message is too large, it might span multiple data frames.
gRPC has native code generation features due to its protoc compiler, which is compatible with v programming languages. This is particularly beneficial for microservices systems that integrate various services developed in different languages and platforms. Native library dependency for proto code generation is supported in lots of programming framework, like Springboot Java plus Maven. Speeding up the learning curve for developers for RPC is one of the main reasons that gRPC has become so popular nowadays.
gRPC made all the decisions for you to map the RPC layer on top of HTTP. gRPC-generated stubs and skeletons hide HTTP from the client and server, developer has no worries about how the RPC concepts are mapped to HTTP. Developer can focus on the dev/test for business logic implementation.
Next time, we will explore other existing API frameworks, like Rest, GraphQL, SOAP, which are the most famous API frameworks adopted by companies nowadays. Understanding their pros and cons would make it easier for us to choose the appropriate framework in various scenarios.
