Proposed by:
- Young Min Kim - The Trade Desk
This RFC provides a way for the clients to determine if a GraphQL server supports a feature that cannot be discovered through the current GraphQL introspection functionality.
Thus far, a GraphQL client could use the schema introspection to check if a feature is available on a server. For example, a client can discover Defer/Stream through the directives field and Input Union through the mutationType field.
However, some new GraphQL features such as Client Controlled Nullability, Fragment Arguments, and Fragment Modularity change the syntax of the GraphQL documents, which cannot be described via the existing schema introspection. We would like a way to describe a server's supported feature set in an unambigous way.
- A unambigous way to describe a supported feature set
- Open a path for developer tools to validate documents based on the target server's supported features
- TBD
A GraphQL client can choose to test the support by requesting a document with the specific feature and checking errors in response. However, this method requires a client to understand how a server can fail given a specific unsupported feature; how a server returns an error for an unknown syntax (Syntax Error: Expected Name, found !) is different from how a server returns an error for an unknown directive (Unknown directive "defer".). So the status quo is not acceptable.
- Client Controlled Nullability: graphql/graphql-spec#895
- Fragment Arguments: graphql/graphql-spec#865
- Fragment Modularity: #839
TBD
We can add a new field __features under the __Schema type. __features can return a list of features in some shape.
__feature will take an argument for a feature name such as non-nullable-designator and returns some info or null.