Andreas Garnaes

Another way to address this issue is by relaxing the type guarantees around unions and interfaces. It's generally hard to capture these concepts well without a clunky API, and the...

> > Would the loss of type safety be worth the simplified interface for you, @dwwoelfel? > > This looks really nice! We're not really taking advantage of the current...

Thanks for the suggestion! I think it should be possible, though I'm wondering whether an implementation should be allowed to _not_ inherit the doc string, and how to achieve this...

Hey @bram209 😄 I've been toying in my mind with such an idea myself, and I think it could be great for simple GraphQL objects. It's not obvious to me...

> W.r.t. the SDL approach, it looks like the sister project (targeting node.js) has a PR open for SDL parsing & printing! [sikanhe/reason-graphql#31](https://github.com/sikanhe/reason-graphql/pull/31) Yeah, unfortunately it's with a handrolled parser...

Looks good, thanks! 👍 I'm happy to merge this when 0.9.0 is merged in OPAM -- just in case there are any last minute changes required before then.

I don't mind much either way. I hope this can be motivating for further contributions though, so I'm happy to indulge 😄

I've considered having `Schema.schema` raise an exception in case of validation errors. Presumably creating a schema is something that happens once at "boot time", so it should be easy to...

Sorry for the slow response. I have two ideas for how to solve this: - Inspect at the `Graphql_parser.field` passed to the resolver (via `resolve_info.field`). - Make a custom scalar...

> I'm not very familiar with the GraphQL spec, but this discussion could be relevant: [baransu/graphql_ppx_re#26 (comment)](https://github.com/baransu/graphql_ppx_re/issues/26#issuecomment-542182296) > > If this is correct, the current behavior of raising an error...