Add derive-Generic input reader for record types to support input objects

[teh]

We have several constraints:

1. Should be easy to use - this points to using a Haskell data type over e.g. a Map Text Value.
2. Input must be validated against a definition: This allows both a type-class checking against Object name i f and a derive Generic record.
3. Definition itself must be valid in the GraphQL sense. This can be derived both from an Object name i f and a derive Generic record.

Would be nice but not necessary:

• Symmetry with handler definitions, i.e. using Object n i f to define input objects as well.
• Make defaults work somehow, but we have this issue already, and I'm not even sure how it's meant to work when reading e.g. Default values for nested input objects graphql/graphql-js#385

I think 1 in particular points to a derive Generic style input. We could add that to FromValue.

[jml]

What exactly do you mean by "support input objects"? To the extent that we run fromValue on data received from users, we already do this.

Also, "input objects" is a technical term in GraphQL, referring to a restricted type of Object suitable for input.

[teh]

The link is exactly what I mean. I'm not sure where we read input objects? Do we have a generic class already? Can't see it in the code.

[jml]

https://github.com/jml/graphql-api/blob/master/src/GraphQL/Resolver.hs#L265

[teh]

Discussed IRL: There will be no extra metadata other than the data that can be derived generically.

[teh]

This is implemented though the API probably isn't final (see #73)

[EdmundsEcho]

Just to be clear for googlers and to save having to click elsewhere: GraphQL specifies two types of Objects.

• GraphQLObjectType
• GraphQLInputObjectType

At first glance, the two types might seem redundant. But, it turns out there is value in having a distinction between your inputs and outputs for the same object.