On a similar note, Rob Zhu had a great section in his talk about how GraphQL's typesafety (to make the API more robust) tries to address a similar problem but e

On a similar note, Rob Zhu had a great section in his talk about how GraphQL's typesafety (to make the API more robust) tries to address a similar problem but ends up being very nuanced in practice. Linking to the right time: https://youtu.be/djKPtyXhaNE?t=1128 https://youtu.be/djKPtyXhaNE?t=1128 TL;DR: - GraphQL is a descriptive type system not prescriptive. This means that "String" maps to JSON String maps to Javascript utf8 string, but what type that maps to for C++ is not quite clear. Because there are many different ways to represent a string. So which one do we use? As opposed to protobuf client codegen which is prescriptive and unambiguous in what you get. - Encoding custom scalars can cause some confusion because it's not clear what the spec of the custom scalar is. Although, there's been some recent work to make that a little better.[1] - Impedance mismatch with nullability and union types because support is not uniform across languages [1] https://github.com/graphql/graphql-spec/issues/635 https://github.com/graphql/graphql-spec/issues/635