Protocol Buffer Concepts

External

• https://protobuf.dev/programming-guides/proto3/

Internal

• Protocol Buffers

Overview

Protocol Buffers is a language-neutral, platform-neutral, extensible mechanism for serializing structured data. The schema is define once, and it used to generate code that serializes and deserializes schema-conforming data. The main use case for Protocol Buffers is sharing data across programming languages. Data can be written and serialized in one language, sent over the network and then and deserialized and interpreted in a different programming language.

Protocol Buffers offers the following advantages:

• It allows defining types, and the data is fully typed when exchanged. We know the type of data in transit.
• Data is compressed automatically.
• Serialization/deserialization is efficient.
• Comes with a schema, in form of the .proto files, which is used to generate code that writes and reads the data.
• Schema supports embedded documentation.
• Schema can evolve over time in a safe manner. The implementations that rely on schema can stay backward and forward compatible.

One of the disadvantages is that the data is encoded in a binary format, so it can't be visualized with a text editor.

The typical workflow consist in defining the data types, called messages, in Protocol Buffer .proto files, then automatically generating the data structures to support and validate the data types, in the programming language of choice. In Go, the messages are represented as structs. With the help of a framework like gRPC, which uses Protocol Buffers as default serialization format and native mechanism to exchange data, client and server code can also be automatically generated. This renders Protocol Buffer convenient for use as serialization format for microservices.

The current version of the protocol is 3, released mid 2016.

Message

Protocol Buffers represent arbitrary data types as messages. A message has fields. One or more messages are declared in .proto text file with the following format:

syntax = "proto3";

/* Person is used to identify
   a user in the system.
*/
message Person {
  // the age as of person's creation
  int32 age = 1; 
  string first_name = 2;
  string last_name = 3;
  bytes small_picture = 4; // a small JPEG file
  bool is_profile_verified = 5;
  float height = 6;
  repeated string phone_numbers = 7;
}

A message (type) can reference other type:

message Something {
    ...
}

message SomethingElse {
  Something something = 1;
}

Messages can be nested:

message Something {
  ...
  message SomethingElse {
     ...
  }
}

Fields

Each field has a field type, a field name and a field tag

 <field_type> <field_name> = <field_tag>;

Unless explicitly set up by the program, every field is initialized with the default type value in serialized messages.

Field Names

Fields names are not important when the message is serialized/deserialized. Only the tags matter.

Field Types

Protocol Buffer Types

string
bool
bytes
int32	uint32	sint32	fixed32	sfixed32
int64	uint64	sint64	fixed64	sfixed64
float	double
repeated
enum

Field Tags

A tag is an integral value between 1 and 2²⁹-1 (536,879,911). The numbers between 19,000 and 19,999 cannot be used. The tag of an enum's first element must be 0.

Tags from 1 to 15 use one byte of space, so use them for frequently populated fields. The tags from 16 to 2047 use 2 bytes.

Default Value

Every field has a default value, which is defined by the field's type. The default value is always used unless the field is explicitly set up by the program. There's no such a concept as "required" field or "optional" field. If the field is not explicitly set in the program, it takes the default value.

Comments

// this is a single-line comment

/* This is
   a multi-line
   comment.
*/

.proto Files

Multiple messages can be defined in the same .proto file.

Import

Different messages can live in different .proto files and can be imported. This feature encourages modularization and sharing.

The types declared in file B.proto can be imported in the file A.proto by using an import statement in file A.proto. Note that unlike for Go, Protocol Buffer import requires paths to .proto files, not packages.

.
├── pkg
│    └── somethingpb
│         ├── A.pb.go
│         └── B.pb.go
│ 
└── protobuf
     └── somethingpb
          ├── A.proto
          └── B.proto

A.proto:

syntax = "proto3";

option go_package = "./somethingpb";
 
import "./somethingpb/B.proto";  // The .proto file path is relative to 
                                 // the --proto_path used by the compiler.

message A {
  B b = 1;
}

B.proto:

syntax = "proto3";

option go_package = "./somethingpb";

message B {
}

Note that the path used in the import statement is relative to the --proto_path used by the compiler:

 protoc --proto_path=./protobuf --go_out=./pkg somethingpb/A.proto somethingpb/B.proto

There is no correlation between the Go import path and the .proto import path.

For more details on code generation, see:

Go Code Generation

Packages

Protocol Buffers have the concept of package, whose semantics is similar to that of a Go package: a namespace for names. In Protocol Buffer's case, these are message names. When a message is declared in a package, with the package specifier, the package must be imported, and the name of a message must be prefixed with the fully qualified package name if we want to use that message in other packages.

There is no correlation between the Go import path and package name, and the package specifier in the .proto file. The latter is only relevant to the protobuf namespace, while the formers are only relevant to the Go namespace. Conventionally, Go package names end in "pb". Protocol Buffer package names do not follow such convention.

However, if we want to generate Go code from Protocol Buffer files that declare multiple packages, it is a good idea to design Protocol Buffer packages to map onto Go packages - each Protocol Buffer package should have its corresponding Go package. If we maintain this convention, it'll help with code comprehension. To exemplify this, we will declare two different Protocol Buffer packages that are going to be translate into their corresponding, homonymous Go packages.

.
├── go.mod
├── pkg
│    ├── blue
│    │    └── blue.pb.go
│    └── red
│         └── red.pb.go
└── protobuf
     └── protobuf-internal-dir
          ├── blue.proto
          └── red.proto

blue.proto

syntax = "proto3";

option go_package = "./blue";  // The Go package and the Protocol Buffer Package have the same name.
                               // This is not a requirement, but makes the code base easier to understand.

package blue;                  // The Protocol Buffer package and the Go have the same name. This is
                               // not a requirement, but makes the code base easier to understand.

// The "A" name is used both in the "blue" and "red" package, so when used in the "red" package
// will have to be qualified as blue.A.
message A {
}

red.proto

syntax = "proto3";

option go_package = "./red";  // The Go package and the Protocol Buffer Package have the same name.
                              // This is not a requirement, but makes the code base easier to understand.

package red;                  // The Protocol Buffer package and the Go have the same name. This is
                              // not a requirement, but makes the code base easier to understand.

import "protobuf-internal-dir/blue.proto";

// The "A" name is used both in the "blue" and "red" package. They can be used even in the
// same file (this one), if they are appropriately prefixed with the package name.
message A {
  blue.A something = 2;
}

The files are compiled with: protoc \

   --proto_path=./protobuf --go_out=./pkg \
   protobuf-internal-dir/blue.proto protobuf-internal-dir/red.proto

For more details on code generation, see:

Go Code Generation

Go Code Generation

Go Code Generation

Data Evolution with Protocol Buffers

A message is actually a type. "Message" is used probably because the instances of the types defines as such are mainly intended to be sent over the wire.