Introduction to protocol buffers

HTTP/1.1 is the standard that is adopted by the web community. In recent times, HTTP/2 is becoming more popular because of its advantages. Some of the benefits of using HTTP/2 are as follows:

The technical definition from Google about protocol buffers is as follows:

Protocol buffers are a flexible, efficient, automated mechanism for serializing structured data—think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use the specially 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 even update your data structure without breaking deployed programs that are compiled against the "old" format.

Let's look at this in detail. A protocol buffer is a strongly typed specification language. A tight data interface is essential for designing microservices. Protocol buffers allow us to define the data contract between multiple systems. Once a protocol buffer file has been defined, we can compile it to a target programming language. The output of this compilation will be classes and functions in the target programming language. The sender serializes data into a binary format that is transferred over the network. The receiver deserializes the data and consumes it. Basically, protocol buffers are similar to data formats such as JSON and XML, but the latter formats are text-based while protocol buffers are binary.

In Go, protocol buffers can be transported over different transports, such as HTTP/2 and Advanced Message Queuing Protocol (AMQP). They are a transport format similar to JSON but strictly typed, and can only be understood between the client and the server. First, we will understand why protocol buffers (protobufs) exist and how to use them.

Protocol buffers have many advantages over JSON/XML for serializing structured data, such as the following:

We will prove these points while discussing a few examples later in this chapter.