In GraphQL, input types are special object types used to define the structure of data passed as arguments to queries and, especially, mutations. They are defined using the input keyword and are used to group and organize input arguments, improving readability and maintainability.

1
Input types are designed to represent the structure of data that a client needs to send to the server as input for operations like creating or updating data (mutations).
2
You define an input type using the input keyword, followed by the type name and a set of fields within curly braces, similar to how you define object types, but with the input keyword instead of type.

In this example, CreateUserInput is an input type that defines the structure of the data required for creating a new user. The createUser mutation accepts an argument of type CreateUserInput.

Difficulty: 5/10

Topics: InputObjectType, Scalar vs Input, Mutation arguments

Scenario Questions

0-2 years experience

1
We need to add a new mutation to create a blog post that takes title, content, and an optional list of tag IDs. How would you define the input type for this mutation?
2
If a client sends a string where the schema expects an Int in an input object, what error does GraphQL return and why?

2-5 years experience

1
During a code review you notice a mutation is using an output type as an argument instead of an input type, and the server is crashing. How would you diagnose and fix the issue?
2
Our product team wants to make the 'address' field optional in a checkout mutation, but some existing clients still send the full address object. How would you evolve the input type without breaking those clients?

5-8 years experience

1
We have a micro‑service architecture where several services share a common 'UserInput' type. Over time the shape of user data diverges per service. How would you manage input type versioning and avoid coupling between services?
2
A performance audit shows that large nested input objects are causing validation bottlenecks. What strategies could you employ to mitigate the impact while keeping the API expressive?

8+ years experience

1
Our organization is migrating from a monolithic GraphQL server to a federated schema. How would you design a strategy for shared input types to ensure backward compatibility and independent service deployment?
2
When planning a long‑term roadmap, how do you decide whether to expose a complex input object versus multiple scalar arguments, considering client SDK generation and future schema evolution?

Follow-up Questions

❓How does GraphQL enforce that input types can't reference output types?
❓What happens if a client sends an extra field not defined in the input type?
❓Can you reuse an input type across multiple mutations? Why would you do that?