[RFC] Expand GraphQL language #163
Conversation
|
Note I think we can do "best-of-both-worlds" that do a simple pass to lint/check for constructs that are meaningless in specific contexts. This would layer a really simple piece of software on top instead of bifurcating a core component. |
This proposes merging the schema language into the GraphQL language. After some time of thinking about this, I believe this is the best path. There is only one "GraphQL language" and thus only one spec for a parser. I believe this will have substantial simplification forces on GraphQL server libs and client tools and the APIs they expose. This also means the validation phase can be designed to accept both "client GraphQL" and "server GraphQL" rather than two separate utilities with two separate AST and rule structures. Instead we're just likely to want to introduce standard rule sets for each environment. The drawback is explaining the semantics. This diff primarily adds type definition syntax to GraphQL, and it should be made clear that *at present* GraphQL servers do not have semantics for these and in fact will not execute queries which contain them.
Totally agree. The spec should describe that executing a query that contains anything other than Operation or Fragment definitions is illegal. This diff now includes https://github.com/graphql/graphql-js/pull/163/files#diff-7216927a33b2b307f325a8190e6fbf9bR178 which enforces this. |
[RFC] Expand GraphQL language
|
In the short term we simply wanted to define formally this language which appears in the spec. Our client tooling often needs a representation of the schema in order to perform various operations. This is human readable as opposed to the result of a schema query. We also anticipate a number of future uses like client-defined schema over a typeless backend. Things like that. |
|
Would a client-defined schema not use |
Correct. Client-side schema are not responsible for execution, so they don't define resolve functions. This addition is an IDL which is just a grammatic visualization of the same information you can derive from Schema introspection. It's useful for it's human readability, and can be parsed back into a Schema instance to use for many purposes. |
This proposes merging the schema language into the GraphQL language.
After some time of thinking about this, I believe this is the best path. There is only one "GraphQL language" and thus only one spec for a parser.
I believe this will have substantial simplification forces on GraphQL server libs and client tools and the APIs they expose. As an example, GraphiQL will never need a "client mode" to parse and operate on "client GraphQL" and other IDE tools built by the community will only have one language to target.
This also means the validation phase can be designed to accept both "client GraphQL" and "server GraphQL" rather than two separate utilities with two separate AST and rule structures. Instead we're just likely to want to introduce standard rule sets for each environment.
The drawback is explaining the semantics. This diff primarily adds type definition syntax to GraphQL, and it should be made clear that at present GraphQL servers do not have semantics for these and in fact will not execute queries which contain them.
Note: this is a counterproposal to #162