Proposal: Do not require query as a root operation type #490
Comments
|
@jonbudd Without |
|
@IvanGoncharov I'm not an expert here, but surely we can just amend the spec - allowing implementations to generate an empty one that only contains the introspection queries? - to allow introspection queries when there's no query root type. |
|
Hmm, I do see your point, @IvanGoncharov. But I don't think that "The query type must exist at runtime" and "The schema author needs to explicitly mention the query type" are quite the same thing, which is what I think @grantwwu is getting at.
I think it logically follows that a schema author using the type schema definition language shouldn't have to explicitly define the If this idea is displeasing, I think another solution would be to allow authors to declare an empty query type, like is suggested in #218, ie: The problem, though, is that this isn't allowed either according to the spec; Section 3.6 of the spec states that Since a query root type must be an Object type, it can't be empty, making the definition above invalid. That is, unless the implicit fields Meanwhile, if these fields do not count toward the list of fields under the
|
|
Yeah honestly this could just be a feature request for |
Yes, you're right but problem is that this behavior is SDL specific. So schemas defined not as SDL can have And more importantly
It's not since
AFAIK, the idea was to detect developer mistake and to limit the number of corner cases. For example, all GraphQL documentation solutions should add a special check to skip I think it's can be possible to remove this rule but it deserves PR and a proper discussion in it. Anyone wants to be a champion for this proposal and create a PR? |
leebyron
added
👻 Needs Champion
Supporting empty types, e.g. objects, input objects and interfaces without any fields, has concrete use cases. - Support for GraphQL APIs without any `Query` operation type fields, for example, if the API only support mutations or subscriptions (see graphql#490). This allows defining an empty `Query` object type, while still supporting introspection. - Support for algebraic data types (see graphql#568), where `__typename` is the only relevant field - Potentially to support "well-known" (but empty) extensions of the introspection schema (see graphql#300) This is a minimalist spec change, which simply removes the relevant items under the type validation sub sections. It would probably be helpful to motivate the change and mention that one or more fields _should_ be present for a (typically) useful schema. The requirement for composite types (object, input objects and interfaces) to define "one or more fields" was introduced in 0599414. This change references graphql/graphql-js#368, motivating the change with: > Since GraphQL always requires you to select fields down to scalar values, an Object type without any defined fields cannot be accessed in any way in a query. > This could be even more problematic for Input Objects where a required input object argument with no fields could result in a field that is impossible to query without producing an error. With regards to these objections: - It's always possible to select `__typename` and therefore even empty object types can be useful (as e.g. algebraic data types) - Passing an empty input object appears syntactically valid: ```gql mutation { update(input: {}) { name } } ``` I think this proposal fulfills the guiding principles by enabling new capabilities motivated by real use cases. This change does not make any previously valid schema invalid, so largely preseves backwards compatibility. Fixes graphql#568 and graphql#490 at the specification level.
Supporting empty types, e.g. objects, input objects and interfaces without any fields, has concrete use cases. - Support for GraphQL APIs without any `Query` operation type fields, for example, if the API only support mutations or subscriptions (see graphql#490). This allows defining an empty `Query` object type, while still supporting introspection. - Support for algebraic data types (see graphql#568), where `__typename` is the only relevant field - Potentially to support "well-known" (but empty) extensions of the introspection schema (see graphql#300) This is a minimalist spec change, which simply removes the relevant items under the type validation sub sections. It would probably be helpful to motivate the change and mention that one or more fields _should_ be present for a (typically) useful schema. The requirement for composite types (object, input objects and interfaces) to define "one or more fields" was introduced in 0599414. This change references graphql/graphql-js#368, motivating the change with: > Since GraphQL always requires you to select fields down to scalar values, an Object type without any defined fields cannot be accessed in any way in a query. > This could be even more problematic for Input Objects where a required input object argument with no fields could result in a field that is impossible to query without producing an error. With regards to these objections: - It's always possible to select `__typename` and therefore even empty object types can be useful (as e.g. algebraic data types) - Passing an empty input object appears syntactically valid: ```gql mutation { update(input: {}) { name } } ``` I think this proposal fulfills the guiding principles by enabling new capabilities motivated by real use cases. This change does not make any previously valid schema invalid, so largely preseves backwards compatibility. Fixes graphql#568 and graphql#490 at the specification level.
This makes the root query operation type optional like the other types. Schema introspection is unaffected. The `__schema` and `__type` fields were already described as "implicit" and not part of the defined root query operation type. A schema without a root query type therefore only supports these queries. Fixes graphql#490
This makes the root query operation type optional like the other types. Schema introspection is unaffected. The `__schema` and `__type` fields were already described as "implicit" and not part of the defined root query operation type. A schema without a root query type therefore only supports these queries. Fixes graphql#490
This makes the root query operation type optional like the other types. Schema introspection is unaffected. The `__schema` and `__type` fields were already described as "implicit" and not part of the defined root query operation type. A schema without a root query type therefore only supports these queries. Fixes graphql#490
GraphQL specification requires Query type to be present as it is required to run introspection query. Per specification it also shouldn't be possible to generate empty complex types (objects, input objects or interfaces) and they should expose at least a single field. Since root Query type is a special GraphQLObjectType it also has to expose at least a single field. Breaking changes: * at least single Query is required when generating the schema * split `didGenerateQueryType` hook (and corresponding `Mutation` and `Subscription` hooks) into `didGenerateQueryFieldType` (previous functionality) and `didGenerateQueryObjectType` hooks to allow more granular control when generating the schema * default `SchemaGeneratorHooks` now performs validation of generated object types (including special query, mutation and subscription types), input object types and interfaces to ensure we don't generate empty complex object types see: graphql/graphql-spec#490 and graphql/graphql-spec#568
) * BREAKING CHANGE: empty complex types should fail schema generation GraphQL specification requires Query type to be present as it is required to run introspection query. Per specification it also shouldn't be possible to generate empty complex types (objects, input objects or interfaces) and they should expose at least a single field. Since root Query type is a special GraphQLObjectType it also has to expose at least a single field. Breaking changes: * at least single Query is required when generating the schema * split `didGenerateQueryType` hook (and corresponding `Mutation` and `Subscription` hooks) into `didGenerateQueryFieldType` (previous functionality) and `didGenerateQueryObjectType` hooks to allow more granular control when generating the schema * default `SchemaGeneratorHooks` now performs validation of generated object types (including special query, mutation and subscription types), input object types and interfaces to ensure we don't generate empty complex object types see: graphql/graphql-spec#490 and graphql/graphql-spec#568
|
I have the same problem here. I agree that GraphQL should not work if you don't have at least one query configured, but I don't think should throw an exception. |
|
I think A Mutation is also a query, so in my opinion it should be possible to just have a mutation configured, hence to havye any type of query but not just the |
|
I ended up solving my problem as follows:
Maybe it is a possibility of having no query configured, instead of returning an EXCEPTION, GraphQL returns a simple "getHello" query that certifies that the GraphQL server is working? |
…xpediaGroup#541) * BREAKING CHANGE: empty complex types should fail schema generation GraphQL specification requires Query type to be present as it is required to run introspection query. Per specification it also shouldn't be possible to generate empty complex types (objects, input objects or interfaces) and they should expose at least a single field. Since root Query type is a special GraphQLObjectType it also has to expose at least a single field. Breaking changes: * at least single Query is required when generating the schema * split `didGenerateQueryType` hook (and corresponding `Mutation` and `Subscription` hooks) into `didGenerateQueryFieldType` (previous functionality) and `didGenerateQueryObjectType` hooks to allow more granular control when generating the schema * default `SchemaGeneratorHooks` now performs validation of generated object types (including special query, mutation and subscription types), input object types and interfaces to ensure we don't generate empty complex object types see: graphql/graphql-spec#490 and graphql/graphql-spec#568
The official spec states:
Why must the
queryroot operation be provided? It seems to me that it should be perfectly legal to have an API that only contains a mutation or subscription. Especially with the advent of subscriptions, which are similar to queries in that they're only meant for retrieving data rather than modifying it, I'm not sure I see a purpose in requiring a query specifically.Some more details on my specific use case, to provide some more context: I'm employing schema stitching to merge numerous disjoint schemas together and present them as one. I have a subscription that I want to host in its own API, since doesn't logically belong in any of my other APIs; but the GraphQL implementation I'm using expects that a query will exist in the schema, forcing me to add an unnecessary query into my schema. Removing this stipulation from the spec (as well as from the implementation) would allow for this use case.
This stipulation is mentioned in #218, but in a slightly different context, and I think it warrants further discussion.
The text was updated successfully, but these errors were encountered: