[RFC] allow empty selections

[kassens]

Sometimes, product code might only be interested in the existence of an object. Currently, this forces a workaround of either querying __typename or adding a bool field like has_thing.

It seems natural and not too confusing to allow empty selections:

query {
  event {
    location {}
  }
}

The response should either return null or an empty object for location.

(The spec changes are incomplete.)

[leebyron]

Thanks for pushing this! I think we've thought about this so many times over the years that it's time to get crisp about whether we want to do this or not. I think earlier proposals suggested allowing the subselection to be omitted, but that was rejected because it could also be an easy mistake, this variant is less likely to be confused in that way.

Some things that may help:

• Can we collect any kind of useful data about the prevalence of { __typename } or the singleton bool? If this is quite rare, then we should probably be happy to leave the existing behavior. If it's somewhat common, then that's a good argument for this change.

• Audit of effect on execution and validation. I think it should be close to as straightforward as you've defined it here, but we need to look out for places in both the spec and reference implementation where we say "empty" and mean "non-existent"

It would also be really great if you could capture this kind of context into an RFC document as a first step (in /rfcs) that explains the problem, the context, any collected data, this solution as well as others (like omitting the selection set).

[jhusain]

Want to call out that this would also make it easier to implement programs which transform Documents. For example federation might cause fields to be removed from a selection set and inserted into another query, making it easy to end up inadvertently creating an empty selection set. Furthermore Flow/TypeScript types doesn't catch empty selection sets either as you can't reject empty arrays with those type systems. Instead you end up with a runtime error.

[victorandree]

For what it's worth, I'd favor omitting the subselection entirely.

• This is what "empty" currently means in the spec (cf "If {selectionType} is a scalar or enum: The subselection set of that selection must be empty")
• query { event { location {} } } } is currently a syntax error, while query { event { location } } } is a validation error. Loosening validation errors seems like a smaller change than loosening syntax.
• I don't think the cost of mistakingly omitting fields is that high. You'd just get an empty object back, instead of an error.

I think allowing empty object selections would raise the expectation to support empty object types (which is why I'm commenting on this issue, since I worked a bit on this, see #606). You'd open up GraphQL to "marker objects" as it'd remove concerns about having to "select fields down to scalar values". I think this would be a net positive but I think the issues are related.