4 ms·
My understanding is the same. Though I had also come to believe that the primary way to achieve this is via loose constraints, i.e. required fields should be us
by andrewingram 10y ago
My understanding is the same. Though I had also come to believe that the primary way to achieve this is via loose constraints, i.e. required fields should be used VERY sparingly.
This compatibility pattern also leads me to conclude that protocol buffers aren't a suitable model for generating a client-side type system. You'll just end up with structures where everything is a Maybe type, so you end up needing tons of bespoke client-side code to handle the possible permutations.
You need a layer on top of of them to express the true type system suitable for clients, and I believe GraphQL does a great job of this (but I hasten to add that even GraphQL's type system is relatively limited and isn't a magic bullet).
- vardump 10y agogRPC is based on protobuf3, which doesn't support "required" or "optional" in the first place.
- andrewingram 10y agoso everything is optional?
- beastman82 10y agoyes
- euyyn 10y agoExcept primitive types. So this is avoided: > You'll just end up with structures where everything is a Maybe type, so you end up needing tons of bespoke client-side code to handle the possible permutations. Absent primitive values default to zero, while absent message fields are mapped to what makes most sense in the specific programming language (in most of them, "null" or "nil").