Support empty composite types

At a glance

• Identifier: #606
• Stage: RFCX: Closed 2019-10-23T10:18:04Z
• Champion: @victorandree
• PR: Support empty composite types

Timeline

• Added to 2019-12-05 WG agenda
• Mentioned in 2019-12-05 WG notes
• Added to 2019-10-10 WG agenda
• Mentioned in 2019-10-10 WG notes
• 3 commits pushed on 2019-08-28:
  • Add note that __typename can be queried on empty types by @victorandree
  • Add empty input object examples by @victorandree
  • Add note about empty query root operation types by @victorandree
• Spec PR created on 2019-08-05 by victorandree
• Commit pushed: Support empty composite types on 2019-08-05 by @victorandree

---

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 #490). This allows defining an empty Query object type, while still supporting introspection.
• Support for algebraic data types (see #568), where __typename is the only relevant field
• Potentially to support "well-known" (but empty) extensions of the introspection schema (see #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 059941486fcea9b93c5a156fe80df03d2021c0b4. 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:

  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 #568 and fixes #490 at the specification level. I've forked graphql-js to remove the corresponding validations (see https://github.com/victorandree/graphql-js/tree/rfc/empty-objects).