4 ms·
I’m not sure how unpopular this opinion is, but I’d actually argue that there are underrated human benefits to using “just protobuf”, which are not shared by us
by gen220 7y ago
I’m not sure how unpopular this opinion is, but I’d actually argue that there are underrated human benefits to using “just protobuf”, which are not shared by using “just JSON”.
1. Single source of truth for certain types, enums.
2. (assuming you’re using gRPC too) A separate, minimalist, and language-agnostic definition of your service interface, which you can document with comments to your heart’s content, and which (unlike other documentation) can NOT be out of sync with the actual service. I don’t have to read C++ to understand your C++ service should work.
3. Protobufs encourage message type / enum reuse, by allowing you to import other definitions. This might seem trivial, but it’s super important in mediumish orgs that everyone is using the same definition of time, geography, etc. It all adds up to less surprises when you open up a new .proto file.
The kicker is not that you can’t somehow get these things with JSON-over-HTTP, too. It’s that protobufs-over-gRPC won’t work without them. The trade off is that you can’t inspect raw requests unless you have built some tooling around it.
- C4stor 7y agoI think the missing assumption is that doing "just protobuf" is not always a possibility when you in the end have an open API front-facing the internet. So now there is a point in your codebase where you are receiving data in a JSON form. At this point having protobuf elsewhere is not chosing between JSON and protobuf, it's chosing between "json+protobuf" and "json".
- bluGill 7y agoNot really. If you are sane you carefully parse all data from the internet and sanitize it first thing. json+protobuf is in fact an advantage because by keeping your internal and external data formats different you eliminate one class of mistakes where external data makes into internal systems. (this isn't perfect, you can change format without doing sanity checking but it makes it harder to do accidentally, and easier to find in an audit)
- gen220 7y agoIn addition to what my sibling comment says about "sanitizing" external data – which I wholeheartedly agree with – the "open API front-facing the internet" is in the process of changing, if you're talking about normal websites. gRPC-web isn't quite feature complete relative to normal gRPC, but it is getting pretty close, and the gains of avoiding JSON (de-)serialization would be big. I think once the protobuf story has a complete chapter for the front-end, bigger engineering orgs will roll it out much like they're rolling out typescript today. If you're talking about actual developer/public-facing APIs, those will probably remain in JSON land for a while.
- xsmasher 7y ago#1 and #3 can be solved by using TypeScript types to define the schema of your JSON. IMO they're readable enough to serve #2 too. Before someone mentions "JSON schema" - I've tried to use them, and they're difficult to write and impossible to read. Reading/writing TypeScript types are a dream in comparison.