I find this discussion fascinating as my only protobuf experience is with IoT devices on bandwidth-limited connections where every byte matters, so hearing JS w

I find this discussion fascinating as my only protobuf experience is with IoT devices on bandwidth-limited connections where every byte matters, so hearing JS web frontend people talk about the same protocol to transfer "large chunks of real time enduser data" is an interesting far opposite experience. Something "interesting" in the overall IoT protobuf experience is software licensing. I can write software under, GPL, or whatever, to access or otherwise interoperate with a REST API implemented using, BSD, or whatever, no problem as long as it follows reasonably close to generic REST standards. Just look at your swagger API docs or whatever system you use, it'll interoperate just fine. Ditto "most JSON stuff" just write your proprietary code to generate a JSON looking like some text documentation for a server under, perhaps, the MIT license, or whatever other license, and interoperability across licenses is easy and legal. Things get weird with protobuf .proto3 files where the server and ANY clients need to use the same .proto3 file to compile to whatever language they'd like to use. So what license do YOU apply to your .proto3 files to make sure other people can (or intentionally cannot) redistribute your .proto3 or compile software against it, etc? You can, intentionally or accidentally, implement all kinds of lockdown and restriction on APIs using protobufs via innocent or intentional copyright and license selection for a .proto3 file. For better or worse, protobufs are a tool invented primarily to enable the prevention of interoperability. If it was just about saving bytes on the wire we'd be doing IoT using zipped up JSONs or similar technology.