Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Improve doc: graphl-js does not support interfaces and unions with buildSchema #1379
As far as I understand, it is the recommended approach to use a root object when we build the schema with buildSchema, because we cannot associate resolver functions when using buildSchema. With this approach the default resolvers are used (AFAIK). The problem is, that we can not use interfaces or union types (defined with SDL), because we can not associate the resolveType function - is that correct? If yes, how can we provide resolveType when using graphql-js with SDL?
The problem here is, that on graphql.org the examples are written for apollo-server, but the graphl-js examples show another approach!
Is there a reason why graphql-js does not use the same approach as graphql-tools (makeExecuteableSchema)? So writing "explicit" resolver functions and not using default resolvers?
This seems to be very confusing for people, when reading graphql.org and then implementing a graphl-js server.
I appreciate every answer, that clarifies some of my points! Thank you very much!
changed the title
Improve doc: graphl-js does not support interfaces and enums with buildSchema
Jun 9, 2018
Default resolver approach used even in
Specification leaves such technical details to implementers so they are free to implement in a way that appropriates to their language/platform:
So having default resolvers is completely valid according to the spec. Moreover
Personally, I like to organize my resolvers as ES6 classes in the absolute majority of cases. I also found that it's easier to explain how GraphQL is working using ES6 classes than using global resolvers separated from rootValue.
At the same time, I think we need to support adding properties that you can't supply in SDL during
@leebyron Would be great to hear your thoughts on this topic.
@IvanGoncharov Thank you very much for you detailed answer!
Ah ok, that makes it "useable" again. Thanks for the clarification
I formulated that a little bit complicated. Sorry for that. What I meant was, that there is no way to provide explicit resolvers, when using graphql-js (using the SDL approach).
AFAIK not graphl-tools has some kind of default resolver approach, it "just" attaches the given resolvers to the schema instance. Because e.g. apollo uses graphql-js under the hood, the same default resolver strategy is used. But my point here is, that the spec says nothing about default resolvers.
The spec states the function
Is it safe to say (in general for all graphql spec compliant implementations, independent of programming language, ...), that there has to be a resolver function for every field?
I know that some points seem to be nitpicking. I just want to understand that in detail, not criticize.
Thanks for your help.
@Franco992 Before we go deep into GraphQL specification. Also lets state a few points:
I think that this functionality is missing because no one design, implement and submit a PR.
@IvanGoncharov Thanks for your clarification.
You are right - I was too focused on the SDL approach. The manual creation supports to assign resolvers. You are absolutely right.
What would be the difference? Do you have any information on this (Didn't find it in the link)?
On question that goes around in my mind:
Is that true? Can I use this formulation? So is this a need of a implementation? I ask because the specified execution model was always a big advantage of GraphQL for me (query language + runtime in the spec = almost same behaviour on different platform / programming languages).
Thank you very much and sorry for annoying you.