26

We have REST webservices that can serve XML or JSON (WCF). I'm toying with idea of implementing Protobufs. Why?

PROS

  1. Less load on servers.
  2. Smaller message size - less traffic.
  3. It is easier to switch now than later.

CONS

  1. Need to be implemented
  2. Going to be harder to troubleshoot/sniff messages for debugging.
  3. I can enable GZip on server and JSON will consume as much traffic

What is your suggestion and/or experience on this?

Improve this question
3
  • 1
    I looked at the wikipedia page, and was actually more chars per key-value pair, so why dose it have smaller messages?
    – Ramzi Kahil
    Commented Jun 22, 2012 at 16:18
  • Because of serialization. Binary data comes through as binary (byte arrays for example). In addition, it doesn't carry property names in a message. They go by property ordinals. developers.google.com/protocol-buffers/docs/encoding#structure
    – katit
    Commented Jun 22, 2012 at 16:24
  • 10
    Technically you answered your own question, compress the JSON and be done with it. Most importantly you never mention an actual business case for spending money and time on this activity.
    – user7519
    Commented Jun 22, 2012 at 16:41

2 Answers 2

Reset to default
40

Does the business value of implementing them exceed the cost?

If you implement, you need to change not just your server, but all clients (although you can support both formats and only change clients as needed). That will take time and testing, which is a direct cost. And don't underestimate the time taken to really understand protocol buffers (especially the reasons to make field required or optional), and the time taken to integrate the protobuf compiler into your build process.

So does the value exceed that? Are you faced with a choice of "our bandwidth costs are X% of our revenues and we can't support that"? Or even "we need to spend $20,000 to add servers to support JSON"?

Unless you have a pressing business need, your "pros" aren't really pros, just premature optimization.

Improve this answer
23

i maintain apis and somebody before me added protobuf (because it was "faster"). The only thing faster is RTT because of of smaller payload, and that can be fixed with gzipped JSON.

The part that is distasteful to me is the relative work to maintain protobuf (compared to JSON). I use java so we use Jackson object mapping for JSON. Adding to a response means adding a field to a POJO. But for protobuf I have to modify the .proto file, then update the serialization and deserialization logic which moves the data in/out of the protocol buffers and into POJOs. It's happened more than once that a release has happened where someone added a field and forgot to put in either the serialization or deserialization code for the protocol buffers.

Now that clients have implemented against the protocol buffers, it's almost impossible to get away from.

You can probably guess from this, my advice is don't do it.

Improve this answer
2
  • 5
    If you're writing (de)serialization code to move data in/out of POJOs, you're doing it wrong. Just use the protobuf-generated classes directly.
    – Marcelo Cantos
    Commented Dec 18, 2015 at 10:42
  • I think in that case I was moving in/out of POJOs because the codebase supported both JSON, XML, and Protobuf requests/responses, and given that I can't add Jackson and/or JAXB annotations to protobuf generated classes, and I want to use the same model objects throughout the code, I don't know that I have options to just use the generated classes. I can see how this would be possible to do if I was writing say GRPC services that only talk protobuf.
    – Kevin
    Commented Sep 10, 2018 at 21:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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