Input type for complex arguments in GraphQL - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

What is the output of this GraphQL query with complex input?

Given the following GraphQL schema snippet:

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

type Query {
  getUserAddress(id: ID!, address: AddressInput!): String
}

And this query:

{
  getUserAddress(id: "123", address: {street: "Main St", city: "Springfield", zip: "01101"})
}

What is the expected output assuming the resolver returns the concatenated address string?

A {"data": {"getUserAddress": "Main St, Springfield"}}

B {"data": {"getUserAddress": "Main St Springfield 01101"}}

C {"data": {"getUserAddress": "Main St, Springfield, 01101"}}

D {"errors": [{"message": "Field 'zip' is required"}]}

💡 Hint

Check how the input type fields are used and if optional fields are included.

The input type AddressInput includes zip as optional, but it is provided in the query. The resolver concatenates all fields with commas, so the output includes all three parts separated by commas.

📝 Syntax

intermediate

Which option is a valid GraphQL input type definition for a complex argument?

Choose the correct GraphQL input type definition for a complex argument representing a product with name (string), price (float), and tags (list of strings).

A

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

B

input ProductInput {
  name: String!
  price: Float!
  tags: [String!]!
}

C

input ProductInput {
  name: String
  price: Int
  tags: String
}

D

type ProductInput {
  name: String!
  price: Float!
  tags: [String!]!
}

💡 Hint

Remember input types use input keyword and field types must match expected data.

Option B correctly uses input keyword, required fields with !, and a list of non-null strings for tags. Option B uses type which is invalid for input. Options C and D have wrong types or missing list structure.

🔧 Debug

advanced

Why does this GraphQL query fail with a validation error?

Given this input type and query:

input FilterInput {
  category: String
  priceRange: [Float!]
}

query getProducts($filter: FilterInput!) {
  products(filter: $filter) {
    id
    name
  }
}

Variables sent:

{"filter": {"category": "Books", "priceRange": [10, null, 30]}}

Why does the query fail?

A Because 'priceRange' contains a null value but is defined as a list of non-null floats.

B Because the variable 'filter' is missing required fields.

C Because 'category' is optional but provided as a string.

D Because the query is missing a selection set for 'products'.

💡 Hint

Check the nullability of list elements in the input type.

The input type defines 'priceRange' as a list of non-null floats ([Float!]), so null values inside the list are not allowed. The variable includes a null element, causing validation failure.

❓ optimization

advanced

How to optimize a GraphQL mutation with complex input to reduce payload size?

You have a mutation that accepts a complex input type with many optional fields. Which approach best reduces the payload size sent from client to server?

A Send only the fields that have changed values in the input object.

B Use a list of key-value pairs instead of an input object.

C Convert the input object to a JSON string and send as a single scalar.

D Send all fields with default or null values to ensure completeness.

💡 Hint

Think about minimizing data transfer by avoiding unnecessary fields.

Sending only changed fields reduces payload size and improves efficiency. Sending all fields or converting to JSON string increases size or complexity. Using key-value pairs is not standard and may complicate schema.

🧠 Conceptual

expert

What is the main reason GraphQL uses input types for complex arguments instead of regular object types?

Choose the best explanation for why GraphQL requires separate input types for complex arguments rather than reusing type definitions.

A Input types automatically generate database schemas, unlike regular types.

B Input types allow circular references which regular object types do not support.

C Input types can include subscriptions which regular types cannot.

D Input types are designed to be immutable and cannot have fields that resolve to functions, ensuring safe input validation.

💡 Hint

Consider the difference in purpose between input and output types in GraphQL.

Input types are restricted to fields with input data only and cannot have resolvers or functions, which prevents side effects and ensures safe validation. Regular object types can have resolvers and are used for output data.