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
There are various problems when trying to build a schema that make the API more confusing.
Inferring a schema comes with the problem of it not being intuitive where build will check for the operations. Can they all be type dependencies? Do they all have to be in the AST?
Schema must declare directives and types and these cannot be lazily evaluated, meaning that for this particular use case build wouldn't support thunks for type dependencies. This is inconsistent.
Finally, because a GraphQL schema does not have a name, it's impossible to deterministically set the schema config via the config argument of build.
Perhaps it would be best to delegate schema creation to a separate function and use build only for types. While it adds an extra function it reduces complexity by separating concerns.
The text was updated successfully, but these errors were encountered:
For the next release (v0.1.0) we'll do the following:
Keep schema inference with operations in any combination of AST or type dependencies. Good error messages (Error messages for better developer experience #4) are critical for this. We'll remove inferred schemas for simplicity and add it in the future if it's something developers want.
There are various problems when trying to build a schema that make the API more confusing.
build
will check for the operations. Can they all be type dependencies? Do they all have to be in the AST?build
wouldn't support thunks for type dependencies. This is inconsistent.build
.Perhaps it would be best to delegate schema creation to a separate function and use
build
only for types. While it adds an extra function it reduces complexity by separating concerns.The text was updated successfully, but these errors were encountered: