gRPC Introduction — Part 2

gRPC — Introduction

If you haven’t gone through the first part, I’d request you to go through it before this one. You can find the first part here: https://medium.com/@abhishekagarwalab.ag/grpc-introduction-part-1-8c91fc7dd848

In the last part, we went over the RPC part of gRPC and discussed when and why should we use RPC over REST.

In this part, we will go through the types of RPC available and specifically, why gRPC is preferred over the others.

Types of RPC

JSON-RPC: JSON-RPC is a stateless, light-weight remote procedure call protocol encoded in JSON. As the name suggests, any data sent or received because of some action is of type ‘JSON’. JSON (JavaScript Object Notation) is a lightweight object serialization format easy to use in most programming languages and has limited syntax. Because the format was derived from JavaScript’s object literal syntax, it is easy to consume from JavaScript which makes it attractive for interactive web applications.

XML-RPC: XML-RPC protocol uses XML to encode its calls and HTTP as a transport mechanism. In XML-RPC, a client performs an RPC by sending an HTTP request to a server that implements XML-RPC and receives the HTTP response. XML (Extensible Markup Language) is a markup language and data interchange format, with support in almost all programming language standard libraries. Serialization or deserialization of XML can be cumbersome in some languages, though many libraries exist to make it easier.

gRPC: gRPC uses protocol buffers which is a method of serializing structured data. It is useful in developing programs to communicate with each other over a wire or for storing data. Protocol buffers are language-neutral, platform-neutral, and extensible. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages. You can think of protocol buffers as defining a ‘schema’ and generating some code that will help you in reading and writing your data as per the schema. The data communicated over gRPC is binary and, therefore, light-weight. With protocol buffers and gRPC, you need not worry about the source and destination technologies/programming languages. It’s all zeroes and ones.

Protocol Buffers

Most of us are familiar with JSON and/or XML. So let’s expand the idea of protocol buffers.

1. Protocol buffer is a binary encoding format that allows you to specify a schema for your data. This helps us in encoding the logics of a certain requirement and enforce rules and synchronisation.
2. In JSON and XML, the data and context aren’t separate, but that’s not the case in Protocol buffers. Comparing it to JSON, it has a pre-defined and larger set of data types. This feature is helpful in automatic validation of the data. JSON is mostly string, which is why encoding and decoding integer and float values is slow compared to protocol buffer.
3. In JSON, there is no size or count present for the header of the body. As a result, parsing a string or array or an object in JSON requires scanning them sequentially. But this is not the case in protocol buffers which increases the performance.
4. This cannot be stressed enough that the schema architecture and the binary format for communication make protocol buffer a simple and smart choice for polyglot applications.

Performance

gRPC is designed to support high-performance and high-productivity open-source RPCs in many languages. gRPC is around 5–7 times faster than REST when receiving data & around 10 times faster than REST when sending data. This is mainly because of the tight packing of the Protocol Buffers and the use of HTTP/2 by gRPC.

gRPC supports bi-directional streaming with HTTP/2 based transport. HTTP/2 can send multiple requests for data in parallel over a single TCP connection. Only one connection to the server is used to load a website, and that connection remains open as long as the website is open. This reduces the number of round trips needed to set up multiple TCP connections. This reduces the number of TCP connections to the server and hence reducing the memory usage.

HTTP/2 supports multiplexing using which multiple requests are allowed at the same time, on the same connection.

HTTP/2 uses a binary converter to convert text into binary before transmitting it over the network. No additional time is wasted translating information from text to binary. Since protocol buffer and gRPC transmit data in binary, the communication between the server and client is fast.

In the next part, we will talk about performance in terms of numbers. We will benchmark gRPC with protocol buffer and compare it with JSON.

TL;DR

With all the benefits offered by gRPC, I would suggest you to try it out once. That being said, I would also like to point out that using a certain technology is up to you and your application requirements. There are certain disadvantages of using gRPC that might affect your decision of using gRPC with protocol buffer.

Now that we are familiar with gRPC and protocol buffers, we can jump over to implementation of a simple gRPC service using protocol buffers and see it in action along with its performance benchmark in the next part.