Input type for complex arguments in GraphQL - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is an input type in GraphQL?

An input type in GraphQL is a special kind of type used to define complex arguments for queries or mutations. It groups multiple fields together so you can pass structured data as a single argument.

intermediate

Why do we use input types instead of regular object types for arguments?

Input types are designed specifically for input data and cannot have fields that are other object types with resolvers. This keeps input data simple and safe, avoiding execution of server-side logic during input parsing.

beginner

How do you define an input type for a complex argument in GraphQL?

You define an input type using the input keyword followed by the input name and its fields. For example:

input AddressInput {
  street: String!
  city: String!
  zip: String
}

intermediate

Can input types contain other input types as fields?

Yes, input types can nest other input types as fields. This allows building complex structured inputs by composing smaller input types.

beginner

Give an example of using an input type in a mutation argument.

Example mutation using an input type:

input UserInput {
  name: String!
  email: String!
}

type Mutation {
  createUser(input: UserInput!): User
}

This lets you pass a structured input argument when calling createUser.

What keyword is used to define an input type in GraphQL?

A input

B type

C interface

D enum

The input keyword defines input types, which are used for complex arguments.

Can input types have fields that are regular object types with resolvers?

A Yes, always

B No, input types cannot have object type fields

C Only if marked nullable

D Only in mutations

Input types cannot have fields that are regular object types with resolvers to avoid execution logic during input parsing.

Which of these is a valid use of an input type?

A As a return type of a query

B As a directive

C As an argument type for a mutation

D As a field inside a regular object type

Input types are used as argument types, especially for mutations, to pass complex structured data.

Can input types be nested inside other input types?

A Yes

B No

C Only in queries

D Only if scalar

Input types can contain other input types as fields to build complex inputs.

Which of the following is NOT allowed in an input type field?

A Scalar types like String or Int

B Lists of scalars

C Other input types

D Object types with resolvers

Input types cannot include object types with resolvers as fields.

Explain what an input type is in GraphQL and why it is useful for complex arguments.

Think about how you send multiple pieces of related data in one argument.

Describe how to define and use an input type in a GraphQL mutation.

Imagine creating a new user with multiple details sent together.

Practice

1. What is the main purpose of using input types in GraphQL queries or mutations?

easy

A. To define the output format of a query

B. To create database tables automatically

C. To group related input fields into a reusable structure

D. To write comments inside the schema

Solution

1. Step 1: Understand the role of input types

   Input types in GraphQL are designed to group related fields together for passing complex arguments.

2. Step 2: Differentiate input from output types

   Input types are not for output or database creation but for structuring inputs in queries or mutations.

3. Final Answer:

   To group related input fields into a reusable structure -> Option C

4. Quick Check:

   Input types = group related inputs [OK]

Hint: Input types group inputs, not outputs or tables [OK]

Common Mistakes:

• Confusing input types with output types
• Thinking input types create database tables
• Assuming input types are for comments

2. Which of the following is the correct way to define an input type in GraphQL?

easy

A. type UserInput { name: String, age: Int }

B. input UserInput { name: String, age: Int }

C. interface UserInput { name: String, age: Int }

D. enum UserInput { name, age }

Solution

1. Step 1: Recall GraphQL syntax for input types

   Input types are defined using the input keyword, not type, interface, or enum.

2. Step 2: Verify the structure

   The correct syntax is input UserInput { name: String, age: Int }.

3. Final Answer:

   input UserInput { name: String, age: Int } -> Option B

4. Quick Check:

   Input types use 'input' keyword [OK]

Hint: Use 'input' keyword to define input types [OK]

Common Mistakes:

• Using 'type' instead of 'input' for input types
• Confusing input with interface or enum
• Missing curly braces or commas

3. Given the input type definition:

input AddressInput { street: String, city: String }

and the mutation:

mutation AddAddress($address: AddressInput!) { addAddress(address: $address) { id } }

What is the correct way to pass the variable $address in a GraphQL request?

medium

A. { "address": null }

B. { "address": "123 Main St, Springfield" }

C. { "address": ["123 Main St", "Springfield"] }

D. { "address": { "street": "123 Main St", "city": "Springfield" } }

Solution

1. Step 1: Understand input type structure

   The input type expects an object with fields street and city, both strings.

2. Step 2: Match variable format to input type

   The variable must be a JSON object with keys matching the input fields, so { "address": { "street": "123 Main St", "city": "Springfield" } } is correct.

3. Final Answer:

   { "address": { "street": "123 Main St", "city": "Springfield" } } -> Option D

4. Quick Check:

   Input variables match input type fields [OK]

Hint: Pass input variables as objects matching input type fields [OK]

Common Mistakes:

• Passing input as a string instead of object
• Using array instead of object for input
• Passing null when input is required

4. Consider this input type and mutation:

input ProductInput { name: String!, price: Float! }

mutation AddProduct($product: ProductInput!) { addProduct(product: $product) { id } }

If you send the variable { "product": { "name": "Book" } }, what error will occur?

medium

A. Runtime error: price field is required but missing

B. No error, mutation succeeds

C. Syntax error: missing price field

D. Type error: name should be Int

Solution

1. Step 1: Check required fields in input type

   Both name and price are marked with !, meaning they are required.

2. Step 2: Analyze provided variables

   The variable only provides name, missing price, so GraphQL will raise a runtime error for missing required field.

3. Final Answer:

   Runtime error: price field is required but missing -> Option A

4. Quick Check:

   Required fields missing cause runtime errors [OK]

Hint: Required fields must be present in input variables [OK]

Common Mistakes:

• Assuming missing required fields cause syntax errors
• Thinking mutation succeeds without required fields
• Confusing field types (e.g., name as Int)

5. You want to create a mutation that accepts a complex input type with nested inputs for a user profile:

input AddressInput { street: String!, city: String! }

input UserProfileInput { name: String!, age: Int, address: AddressInput! }

Which of the following mutation argument definitions correctly uses these input types?

hard

A. mutation updateUserProfile(profile: UserProfileInput!) { ... }

B. mutation updateUserProfile(profile: UserProfileInput) { ... }

C. mutation updateUserProfile(profile: AddressInput!) { ... }

D. mutation updateUserProfile(profile: String!) { ... }

Solution

1. Step 1: Identify correct input type for mutation argument

   The mutation should accept the full user profile input, which is UserProfileInput, not just the address or a string.

2. Step 2: Check required modifier

   Since the profile is required, the argument should be UserProfileInput! to enforce presence.

3. Final Answer:

   mutation updateUserProfile(profile: UserProfileInput!) { ... } -> Option A

4. Quick Check:

   Use full nested input type with ! for required [OK]

Hint: Use full nested input type with ! if required [OK]

Common Mistakes:

• Using nested input type instead of full input type
• Omitting required ! modifier
• Using scalar types instead of input types