graphql/graphql-spec#820

Matt: I have to deal with a codebase restricted by this problem. We used "Type models" at Facebook at the beginning of GraphQL. In the last 6 years we've used "Response models" - models that map what the fields in the JSON response are going to give us. It's okay if a JSON object has a key that can map to other (different) objects; but it's not so good if the same key on the object might sometimes be an integer, sometimes a string. It's impossible for us to lift this restriction, and Relay would have this problem too - you have to use aliases in order to solve this.
[...]
Matt: to do that we'd need to make a strong recommendation that clients that get built do not use response models.
Andi: I'm happy to understand the reasoning behind this decision, and that Sasha already raised it.
Michel: lifting this restriction would add value to clients because it allows for new use cases e.g. differentiating types.
Lee: we have this rule so that painfully sub-par type generators can support it, but if you want to allow that you can implement an additional validation rule of your own.
Lee: ACTION: Add prose or a non-normative note to this validation rule to explain this. (Overlapping field can be merged.)
Andi: adding prose would be great to explain why objects and scalars are different here.

• assignee(s): @leebyron
• source: https://github.com/graphql/graphql-wg/blob/main/notes/2021-03-04.md#allow-fields-to-diverge-more-15m-andi

Note: Action Item issues are reviewed and closed during Working Group
meetings.