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.

1
Query: For fetching data. The query root operation type must be provided and must be an Object type.
2
Mutation: For modifying data (create, update, delete). 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.
3
Subscription: For real-time data (using WebSockets). 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.

Difficulty: 3/10

Topics: root operation types, schema design, authorization

Scenario Questions

0-2 years experience

1
If you need to add a new read‑only endpoint to your GraphQL API, which root operation type would you use and why?
2
What happens if you define a field under Mutation but never send any mutation queries to it?
3
How would you expose a real‑time price feed using GraphQL's root types?

2-5 years experience

1
Your team added a new field to the Query type, but clients are getting 'field not found' errors. Walk me through how you'd debug this.
2
We want to support both queries and subscriptions for a chat app. How would you decide which root type to place a 'messages' field under, and what trade‑offs are involved?
3
During a refactor, a developer moved a mutation resolver into the Query type. What issues could arise at runtime?

5-8 years experience

1
Design a GraphQL schema for a microservice that needs to expose read, write, and real‑time updates. How would you structure the root operation types to keep the service maintainable at scale?
2
When integrating GraphQL with an existing REST API that has both synchronous and event‑driven endpoints, how do you map those to root operation types while minimizing coupling?
3
Explain how you would enforce that only certain clients can execute mutations, using root operation type separation and middleware.

8+ years experience

1
Our organization is consolidating multiple GraphQL services into a federated gateway. How would you standardize root operation types across teams to avoid conflicts and support future evolution?
2
We need to version our API without breaking existing clients. Discuss strategies involving root operation types and schema stitching to achieve a smooth migration.
3
Consider a scenario where you must deprecate a Mutation in favor of a Subscription for real‑time data. How would you plan the transition at the architectural level, ensuring backward compatibility?

Follow-up Questions

❓What would you do if a client tries to use a mutation on a Query field?
❓How do you handle schema changes that affect root types in production?
❓Can you describe any pitfalls when mixing subscriptions with queries?