How size of message gets reduced when sent as Protocol Buffers as compare to JSON

Viewed 306

I am learning gRPC. I know the size of message gets reduced when it is sent using protocol buffers.

// JSON - 55 bytes
{
  "age": 35,
  "first_name": "Stephane",
  "last_name": "Marrek"
}

Same message in Protocol Buffers,

// Binary - 20 bytes
message Person {
  int32 age = 1;
  string first_name = 2;
  string last_name = 3;
}
  1. What does it mean by JSON is transferred as string and protocol buffers as binary? Isn't at the end they sent as binary?
  2. How the size of protocol buffers is reduced as compare to JSON
  3. Parsing JSON is cpu intensive. What about deserializing binary protocol buffers?
2 Answers
  1. What does it mean by JSON is transferred as string and protocol buffers as binary? Isn't at the end they sent as binary?

Let's understand this from a basic perspective.

gRPC is a technology that implements RPC (Remote Procedure Call) API over HTTP 2.0 protocol. This is widely adopted to build microservices where two services can talk to each other in a more efficient way. A protocol buffer is an IDL(Interface definition language) which gRPC framework use to leverage this infrastructure. This is similar to WSDL which we see in the SOAP world.

For inter-service communication, we pass the messages over the wire. In more traditional we encounter JSON, XML to transmit messages between services. These types of messages can be transferred over any supporting HTTP protocol in form of text-based. These messages carry a payload as well as headers.

In the case of gRPC, its protocol buffer defines the message format and the mechanism to encode and decode these messages. This message is carried over HTTP 2.0 which is a binary protocol that means data are transferred in binary format. It's the HTTP 2.0 infra that transmits these messages in binary format. Here messages do not need all the heavy schema (Unlike text-based JSON), all the headers are compressed which in turn reduces the overhead, reduces latency, and increases the performance/throughput.

whereas gRPC set all the ground for it. It gives the mechanism to encode and decode these messages.

Summary:- So in the case of gRPC, these messages are transferring in binary format over HTTP 2.0, whereas in the case of JSON these messages are transmitted over any HTTP protocol in text-based.

  1. How the size of protocol buffers is reduced as compared to JSON

As I explained we don't need schema unlike JSON in gRPC message communication. This saves all those bytes. You just send the data bytes, and at another end, the gRPC framework will take care of deserializing it if required.

  1. Parsing JSON is cpu intensive. What about deserializing binary protocol buffers?

gRPC has binary serialization/deserialization. which is fast. In simple terms, you can understand it in this way. In the case of text-based encoding, the decoder first translates the message into the machine-readable format, and then we work on it. In the case of binary data, this overhead can be reduced significantly.

JSON documents are transmitted in some UTF encoding. Usually UTF-8, but UTF16 BE and LE, and UTF32 BE and LE are allowed. JSON is human readable text.

The data size is mostly reduced because field names (age, first_name, last_name) are transmitted in JSON. An array of 10,000 strings will have very little size reduction.

I have a shipping app that reads about 10 MB of JSON data on launch. That was acceptable years ago on an iPhone 4s. On a modern iPhone, no sweat at all.

Pro's for JSON: No need to use any tools, to add any third-party code to your app. Very flexible with un-planned extensions, because the JSON literally describes what it contains. Go with JSON unless you have evidence that using protocol buffers improves sales or saves you money.

Related