Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Support empty composite types #606

Closed
wants to merge 4 commits into from

Commits on Aug 28, 2019

  1. Support empty composite types

    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.
    victorandree committed Aug 28, 2019
    Configuration menu
    Copy the full SHA
    1845261 View commit details
    Browse the repository at this point in the history
  2. Configuration menu
    Copy the full SHA
    acae03a View commit details
    Browse the repository at this point in the history
  3. Configuration menu
    Copy the full SHA
    b9d667d View commit details
    Browse the repository at this point in the history
  4. Configuration menu
    Copy the full SHA
    2ec437f View commit details
    Browse the repository at this point in the history