First, what even is Protobuf? We’ll let Google explain:
“Protobuf (Protocol buffers) are Google’s language-neutral, platform-neutral, extensible 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 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.”
In other words, a small binary format payload is used that can be interpreted by the receiver using the same, or different, language.
For example, the sender can use strongly typed .NET C# and the receiver can use Java – either side doesn’t need to know what the other is using. The common artifact is a simple shared schema, e.g.
You’ve got JSON, so why should you care?
While Protobuf sounds really interesting, you’re probably asking yourself ‘What’s wrong with JSON?’
Well, for starters, the Protobuf payload is strongly defined by a portable schema. Secondly, Protobuf definitions are backward compatible using numbered fields. These definitions also have the advantage of built-in validation and extensibility.
Having said that, JSON does have its place when consuming it directly in a web browser, or you want a message to be human-readable.
Why and where should you use Protobuf?
Protobuf is easy to use in microservices, especially where performance and interoperability is important.
There are many tutorials out there to help you get started. Google has one for several languages on its developer site: https://developers.google.com/protocol-buffers/docs/tutorials.
After saying JSON may be better for web browser apps, Microsoft has brought gRPC-Web experimental support to .NET1. You might find this gRPC-Web Hello World Guide worth your while to read. Another use for Protobuf is with gRPC. gRPC uses Protobuf by default to aid high performance and high productivity:
“Like many RPC systems, gRPC is based around the idea of defining a service, specifying the methods that can be called remotely with their parameters and return types. By default, gRPC uses protocol buffers as the Interface Definition Language (IDL) for describing both the service interface and the structure of the payload messages.”
Protobuf vs. JSON. Choose your moments
We recommend you use Protobuf when:
- You need fast serialisation/deserialisation
- Type safety is important
- Schema adherence is required
- You want to reduce coding
- Language interoperability is required
- You want to use the latest shiny toy
Consider JSON or other formats when:
- You want the data to be human readable
- Data is consumed by a web browser
- Schema adherence isn’t a concern
- You want to reduce coding
Some argue that Protobuf may really only be useful if you are trying to squeeze the last fraction of performance from your web services, and it isn’t necessarily worth the effort for most applications. However, we recommend becoming familiar with it anyway. The time may come when it’s the perfect fit for your requirements, or you may be charged with maintaining it.
References
https://developers.google.com/protocol-buffers
https://auth0.com/blog/beating-json-performance-with-protobuf/
https://stackoverflow.com/questions/52409579/protocol-buffer-vs-json-when-to-choose-one-over-another
https://www.grpc.io/docs/guides/
https://www.grpc.io/docs/guides/concepts/
https://en.wikipedia.org/wiki/Protocol_Buffers
https://codeclimate.com/blog/choose-protocol-buffers/
Note: gRPC is not supported on Azure App Service “ASP.NET Core gRPC is not currently supported on Azure App Service or IIS. The HTTP/2 implementation of Http.Sys does not support HTTP response trailing headers which gRPC relies on. For more information, see this GitHub issue (https://github.com/dotnet/AspNetCore/issues/9020).”
The opinions expressed in our blogs are those of the individual contributors, not necessarily those of Adaptiv Integration. We encourage our people to lead, not follow, and to add value by sharing their experience and unique insights.
