Add InputUnion problem statement

[binaryseed]

This PR adds a section to the InputUnion RFC document that provides an overview of the problem being addressed.

Open to feedback!

@IvanGoncharov @leebyron @benjie

[benjie]

This is great!

I've tried to take on the role of editor and added suggestions to make the text slightly more formal, and have replaced instances of APIs with GraphQL schema as appropriate to be more explicit/accurate. I've softened the language in a few places (and strengthened it in others).

One thing I'm concerened with is that it seems to focus on mutations, but using input unions in queries is also a desired outcome of this solution. Accommodating that in the text would be wonderful. I'm not sure how to do this concisely.

Once issue that I think needs addressing is the reference to Dog, Cat etc as the input types, whilst also talking about how the input types should mirror the output types. If Dog and Cat are the input types, what are the output types called? I suggest renaming all input type references to be *Input throughout, for example AnimalInput, CatInput, etc. This is particularly important with the final __typename reference to "Dog" which seems like it's pointing at an output type.

Let me know what you think, hopefully this feedback is helpful 😄

[IvanGoncharov]

@binaryseed Thanks for keeping the ball rolling 👍
But I don't agree that the core problem here is that:

GraphQL currently provides abstract types that operate on Object types, but they aren't allowed on Input types.

GraphQL has two distinct type systems by design: nominal (for output type) and structural (for input types). But the current problem statement looks like core issue here is to switch input types to nominal and support abstract types. That definitely can be one of the solutions but it's not the only one, e.g. @benjie @oneField proposal doesn't add any abstract type and keeps input types nominal.

I think we need to describe what we want to achieve and not how we want to do that.
So I think core problem here is the ability to describe complex input types that can have multiple shapes (e.g. sets of fields) without losing type-safety so instead of abstract type we can use polymorphic type.

I also think the problem statement should be short and mutation example (with tag union workaround) should be part of use cases section because right now it looks like it's the only problem we trying to solve.

[benjie]

Fantastic work @binaryseed 💯 🙌

[IvanGoncharov]

Merged 🎉
@binaryseed Thanks a lot for keeping the ball rolling 👍
@benjie @jturkel Thanks for taking the time to review 👍