Proposal: Do not require query as a root operation type

[jonbudd]

The official spec states:

A schema defines the initial root operation type for each kind of operation it supports: query, mutation, and subscription; this determines the place in the type system where those operations begin.
The query root operation type must be provided and must be an Object type.
The mutation root operation type is optional; if it is not provided, the service does not support mutations. If it is provided, it must be an Object type.
Similarly, the subscription root operation type is also optional; if it is not provided, the service does not support subscriptions. If it is provided, it must be an Object type.

Why must the query root 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.

[IvanGoncharov]

@jonbudd Without query root type you can't execute introspection query.
How should we solve this problem?

[grantwwu]

@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.

[jonbudd]

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. query already has some other implicit logic:

• Query is assumed to be the name of the query root type when left unspecified
• __type and __schema fields are implicit fields in the query root type

I think it logically follows that a schema author using the type schema definition language shouldn't have to explicitly define the query root type; it should assume that Query is the root type if nothing is present, and then the introspection fields should be applied to that Query type. This set of rules would allow the query type and its introspection fields to still be present at runtime, even when no query root type is defined. This would even allow for "empty" schemas, which only contain introspection queries.

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:

type Query {
}
...

The problem, though, is that this isn't allowed either according to the spec; Section 3.6 of the spec states that 1. An Object type must define one or more fields.

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 __type and __schema count toward its fields. Is this the case? If so, I would say that this should be explicitly stated in the spec so that it's clear that an empty query type is valid according to the type system definition language, since introspection fields are added at runtime. This would ensure that implementation authors don't fall into a trap of thinking that it's not allowed.

Meanwhile, if these fields do not count toward the list of fields under the query type, then we're back at square one, with my use case still being impossible. There are a couple of solutions I can think of to this:

1. Allow Object types to be empty. I'm not sure I understand the reasoning behind forcing them to be nonempty anyway, except to avoid bloat.

2. Change it so that __type and __schema are counted as fields in the Query object by default. This would make it always nonempty, even when it "looks" empty according to the type definition schema language. This makes query somewhat of a special case, but it's already a special case due to the introspection fields being added on any query root type.

[stubailo]

Yeah honestly this could just be a feature request for graphql-js and not a thing for the spec. Perhaps buildSchema('') should be valid, and return a schema that only replies to introspection.

[IvanGoncharov]

I think it logically follows that a schema author using the type schema definition language shouldn't have to explicitly define the query root type;

Yes, you're right but problem is that this behavior is SDL specific. So schemas defined not as SDL can have Query type that does not query root type so we would be forced to add __IntrospectionOnlyQuery or similarly named type.

And more importantly __type, __typename, __schema are implicit fields so any such type will be empty.
So I think to allow the explicitly empty type is the best option we have.

This makes query somewhat of a special case, but it's already a special case due to the introspection fields being added on any query root type.

It's not since __typename added to every type, including query root type.

Allow Object types to be empty. I'm not sure I understand the reasoning behind forcing them to be nonempty anyway, except to avoid bloat.

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 Fields title otherwise it will look strange without a list of fields underneath.
I'm also not sure if all programming languages support empty types and this is important for code generation.

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?