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

Restrict root object identification to ROOT_QUERY. #6914

Merged
merged 2 commits into from
Aug 27, 2020

Conversation

benjamn
Copy link
Member

@benjamn benjamn commented Aug 26, 2020

Although "Mutation" and "Subscription" are technically the default names for the root mutation and subscription types, there should never be any need to refer to those objects, read from them, or write to them, outside the normal process of sending and receiving mutations and subscriptions.

If you think those use cases have any value, #6911 will quickly convince you that the downsides of monopolizing types like Subscription and Mutation (e.g. assuming they are always singletons) dramatically outweigh the benefits.

In fact, it's not even possible to request the __typename field for the root Subscription object, according to the GraphQL specification: https://spec.graphql.org/June2018/#sec-Single-root-field

In particular, whereas

query { __typename }

can be used to find out the __typename of the root query object (which might be something other than "Query" in rare situations), the following operation is illegal, because a subscription must have only a single root field:

subscription MessagesSub {
  __typename
  messages {
    source
    payload
  }
}

This means the only way to find out that the root Subscription type has a __typename other than "Subscription" would be through an introspection query, which is typically disallowed in production.

Although "Mutation" and "Subscription" are technically the default names
for the root mutation and subscription types, there should never be any
need to refer to those objects, read from them, or write to them, outside
the normal process of sending and receiving mutations and subscriptions.

If you think those use cases have any value, #6911 will quickly convince
you that the downsides of monopolizing types like Subscription and
Mutation (e.g. assuming they are always singletons) dramatically outweigh
the benefits.

In fact, it's not even possible to request the __typename field for the
root Subscription object, according to the GraphQL specification:
https://spec.graphql.org/June2018/#sec-Single-root-field

In particular, whereas

  query { __typename }

can be used to find out the __typename of the root query object (which
might be something other than "Query" in rare situations), the following
operation is simply illegal, because a subscription must have only a
single root field:

  subscription sub {
    __typename
    newMessage {
      body
      sender
    }
  }

This means the only way to find out that the root Subscription type has a
__typename other than "Subscription" would be through an introspection
query, which is typically disallowed in production.
@benjamn benjamn added this to the Post 3.0 milestone Aug 26, 2020
@benjamn benjamn self-assigned this Aug 26, 2020
@benjamn benjamn merged commit face567 into main Aug 27, 2020
@benjamn benjamn deleted the restrict-root-object-identification-to-ROOT_QUERY branch August 27, 2020 18:10
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 16, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants