You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With SDL officially part of the specification, would it be worthwhile to provide a way to build a build a fully-featured schema from a Document AST?
Currently, schemas built using buildASTSchema/buildSchema lack several features that are otherwise available if constructed programmatically:
Specifying resolve functions for fields
Specifying resolveType functions for unions and interfaces and isTypeOf functions for types
Specifying enum value values
Adding custom scalars
Workarounds exist for some of these limitations (functions can be passed through the root object for root type fields, abstract types can be handled by explicitly providing a __typename property, etc.). In practice, though, if I'm starting a new project and want to use SDL to define my schema, I'm forced to use graphql-tools or another third-party package. This was completely understandable prior to the 2018 version of the spec, but now it may be appropriate for this functionality to be part of the core library.
The text was updated successfully, but these errors were encountered:
@danielrearden It's one of the goals of buildSchema/extendSchema refactoring I'm working in the background. I still like that simplicity of buildSchema so ATM my long term plan is to create a better version of transformSchema from #1199.
And based on it create a high-level function to attach resolvers to any schema (produced by buildSchema, extendSchema, buildClientSchema, new GraphQLSchema, etc.).
BTW, You can use SDL together with ES6 classes so you don't need to attach resolvers to schema: https://github.com/IvanGoncharov/swapi-demo/blob/master/src/index.ts
That said I still think it extremely important to support the pattern of attaching static resolvers since it's the widest spread pattern in GraphQL JS ecosystem.
With SDL officially part of the specification, would it be worthwhile to provide a way to build a build a fully-featured schema from a Document AST?
Currently, schemas built using
buildASTSchema
/buildSchema
lack several features that are otherwise available if constructed programmatically:resolve
functions for fieldsresolveType
functions for unions and interfaces andisTypeOf
functions for typesWorkarounds exist for some of these limitations (functions can be passed through the root object for root type fields, abstract types can be handled by explicitly providing a
__typename
property, etc.). In practice, though, if I'm starting a new project and want to use SDL to define my schema, I'm forced to usegraphql-tools
or another third-party package. This was completely understandable prior to the 2018 version of the spec, but now it may be appropriate for this functionality to be part of the core library.The text was updated successfully, but these errors were encountered: