5

Protobuf is a good thing, it allows c++ devs to not bother with class serialization/deserialization, is fast and .proto format is very nice. It also allows automatic data validation. But the messages are not human readable, and most importantly not human craftable. Which is a problem when you need to quickly test the response to a certain stimuli from a remote server.

The solution, as it seems to me, is to craft protobuf message, convert it to json via some library and send this, using the same library to deserialize it to protobuf on the server and back to c++.

It seems like we get best of both words: message validation, automatic class generation from .proto files and readability of json. Sure it is slower, but for my task speed is not essential. Still, is it sane? Admittedly, I have little knowledge of networking and problems that can arise from described approach. Can someone tell me if there are future problems?

  • 5
    Protocol Buffers already has a "text format" that is similar (if not identical) to JSON. See developers.google.com/protocol-buffers/docs/overview#whynotxml – Robert Harvey Sep 18 '15 at 1:40
  • @RobertHarvey: That text format is not used when transmitting a Protocol Buffers message over the wire, but it is a language-independent way to specify the messages. – Bart van Ingen Schenau Sep 18 '15 at 7:40
  • No, @RobertHarvey is correct, there is a text format for passing messages around.not sure if it is better to use that or json though as they are not the same – Zeks Sep 18 '15 at 12:34
  • @BartvanIngenSchenau: That is the .proto file, not the text format. Protocol Buffers allows you to specify a binary or text wire format, and the text format is modeled on JSON. – Robert Harvey Sep 18 '15 at 15:07
  • @Zeks: The exact format of the message format is not important so long as Protocol Buffers is on both sides of the wire. – Robert Harvey Sep 18 '15 at 15:18
4

Converting Protobuf to JSON and back is perfectly workable, as long as you can handle the performance overhead. I worked on a project where we did something like that, using JSON as the preferred format for ReST calls for lower-performance, high-friendliness. The web-layer converted to Protobuf, which the underlying services used directly. We included a direct Protobuf content-type so you could bypass the JSON encoding/decoding and use Protobuf over HTTP(S).

Certain privileged high-performance clients could access a raw socket interface that implemented a Protobuf/RPC interface onto the same services.

All worked nicely. I don't think any clients converted their protobuf to JSON - but they could have done; the schema was available, and that could have been used for migration or debugging.

EDIT:

As @RobertHarvey observes in his comment, there is a "text formatter/parser" library in protobuf, described here: https://developers.google.com/protocol-buffers/docs/reference/cpp/google.protobuf.text_format. This provides:

Utilities for printing and parsing protocol messages in a human-readable, text-based format

For clarity, this is not a protobuf wire protocol (though I guess it could be crowbarred into being one!), but is a toolkit for helping you to work with protobuf messages as text. It probably means you wouldn't need to use JSON specifically. You could write a tool that would display a protobuf msg as text, edit it, and re-encode.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.