4 ms·
Not the OP, but: Protobufs are much more complicated on the implementation side than JSON. You at minimum need a protobuf library and a spec for your data that'
by SomeCallMeTim 4y ago
Not the OP, but: Protobufs are much more complicated on the implementation side than JSON. You at minimum need a protobuf library and a spec for your data that's shared on client and server. Migrations are also a lot more work because you may need to keep around every version of your protobuf in every client and/or server, depending on how synchronized the two are (i.e., if you can guarantee all clients and servers are upgraded 100% synchronously, as on a web site, then it's not so bad, but if clients are apps or peers that may or may not be upgraded, then the server may need to speak many different versions of a protobuf).
These all qualify as "more heavyweight," at least from an implementation perspective.
- yencabulator 4y ago> because you may need to keep around every version of your protobuf in every client and/or server That shouldn't be necessary. Protobuf changes are supposed to be additions-only, where existing field numbers never change their meaning, but new optional/default fields are added. If you do that, you only need one version of the proto spec.