Caleb Meredith

@OlegIlyenko have you considered introducing only a single directive in the IDL that maps well to introspection that would allow users to provide metadata? Something like `@metadata`. Users could then...

@OlegIlyenko why would you not want to mix disjointed concerns in a single type? There are many ways to design the type to make mixing less confusing. Also, how is...

> One additional aspect is performance. We expose two versions of our api - one that is relay compatible and one that is human readable. For one particular query the...

Mixing scalars and object types would require a change to the schema which is too complex to consider. Schemaless GraphQL clients depend on the guarantee the `{ field }` is...

Another approach inspired by @rmosolgo’s recommendation would to have a type system that looks like: ```graphql union IntOrString = IntBox | StringBox type IntBox { value: Int } type StringBox...

@ianks here’s some related issues on union input types: https://github.com/facebook/graphql/issues/202 and https://github.com/graphql/graphql-js/issues/207

Any ideas for solutions would be great, I'll take a stab at it when I have some time. I didn't understand the depth of this till just now...

I agree the property method might not be the best idea. To my knowledge there is nothing stopping the user from doing this: ``` javascript next() next() ``` In an...

Ok, removed the `next` property in favor of using a `once` wrapper. This error is uncatchable as it would require yet another `next` call (inception bwah). It is to my...

Ok, made the change so that errors would be catchable. However, it is most likely that the response will be sent before the error handlers are triggered, so `res.end` will...