Feature Discovery
At a glance
- Identifier: FeatureDiscovery
- Stage: RFC0: Strawman
- Champion: -
- PR: -
- Related:
Timeline
- RFC document updated on 2023-11-28 by Benjie Gillam
- RFC document created on 2023-08-19 by Young Min Kim
RFC: Feature Discovery
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.
📜 Problem Statement
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 themutationType
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.
✅ RFC Goals
- 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
🚫 RFC Non-goals
- TBD
🗿 Prior Art
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.Related Issues
- Client Controlled Nullability: https://github.com/graphql/graphql-spec/pull/895
- Fragment Arguments: https://github.com/graphql/graphql-spec/pull/865
- Fragment Modularity: https://github.com/graphql/graphql-wg/pull/839
🧑💻 Proposed Solution
TBD
Option A: Extending a schema for schema introspection
We can add a new field
__features
under the__Schema
type.__features
can return a list of features in some shape.Option B: Add a new root-level meta field next to
__schema
and__type
__feature
will take an argument for a feature name such asnon-nullable-designator
and returns some info ornull
.Option C: TBD