Required fields with non-null (!) in GraphQL - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

What is the output of this GraphQL query with non-null fields?

Given the schema where name is String! (non-null), what will be the result of this query?

{ user(id: 1) { id name } }

Assume the user with id=1 exists but has name set to null in the database.

GraphQL

type User {
  id: ID!
  name: String!
}

query {
  user(id: 1) {
    id
    name
  }
}

A The query returns an error because <code>name</code> is non-null but the value is null.

B The query returns the user with <code>name</code> as null.

C The query returns the user but omits the <code>name</code> field.

D The query returns an empty object for <code>user</code>.

💡 Hint

Remember that String! means the field cannot be null in the response.

Since name is marked as non-null (String!), returning a null value violates the schema. GraphQL returns an error instead of null.

🧠 Conceptual

intermediate

Why use non-null (!) fields in GraphQL schemas?

What is the main reason to mark a field as non-null (!) in a GraphQL schema?

A To allow the field to be omitted from the response if null.

B To make the field optional in queries.

C To ensure the client always receives a value and never null for that field.

D To allow the field to accept null values in mutations.

💡 Hint

Think about how non-null affects the response data.

Non-null fields guarantee that the client will always get a value for that field, never null. This helps avoid null checks on the client side.

📝 Syntax

advanced

Which schema definition correctly marks a field as non-null list of non-null strings?

Choose the correct GraphQL schema syntax for a field tags that is a non-null list of non-null strings.

A tags: [String!]!

B tags: [String]!

C tags: [String!]

D !]!gnirtS[ :sgat

💡 Hint

Remember the order of ! affects list and item nullability.

tags: [String!]! means the list itself is non-null and each string inside is also non-null.

🔧 Debug

advanced

Why does this GraphQL query fail with a non-null violation error?

Given this schema:

type Post {
  id: ID!
  title: String!
  content: String
}

And this query:

{ post(id: 5) { id title content } }

The server returns an error about a non-null violation on title. What is the likely cause?

A The <code>id</code> field is missing in the response.

B The <code>content</code> field is null but marked non-null in schema.

C The query syntax is invalid.

D The <code>title</code> field in the database is null for post with id 5.

💡 Hint

Check which fields are non-null and their values in the data.

The title field is non-null but the data has null for it, causing the error.

❓ optimization

expert

How does using non-null fields (!) improve GraphQL query performance?

Which of the following best explains how marking fields as non-null (!) can help optimize GraphQL query execution?

A The server can skip null checks and avoid unnecessary error handling for those fields.

B The client can cache responses more aggressively knowing fields are always present.

C The schema compiler can generate simpler resolvers for non-null fields.

D The server can batch requests for non-null fields separately for faster resolution.

💡 Hint

Think about how clients use non-null guarantees.

Clients can cache and reuse data more efficiently when fields are guaranteed non-null, reducing repeated queries and improving performance.

Practice

1. What does adding ! after a field type in GraphQL schema mean?

easy

A. The field is required and cannot be null

B. The field is optional and can be null

C. The field is deprecated

D. The field is a list type

Solution

1. Step 1: Understand the role of ! in GraphQL

   In GraphQL, adding ! after a type means the field is non-nullable, so it must have a value.

2. Step 2: Interpret the meaning for data completeness

   This means the field is required and cannot be left empty or null, ensuring data completeness.

3. Final Answer:

   The field is required and cannot be null -> Option A

4. Quick Check:

   Non-null ! means required = C [OK]

Hint: Remember: ! means must have a value, no null allowed [OK]

Common Mistakes:

• Thinking ! means optional
• Confusing ! with list type
• Assuming ! marks deprecated fields

2. Which of the following is the correct syntax to declare a required string field named name in GraphQL?

easy

A. name: String

B. name!: String

C. name: !String

D. name: String!

Solution

1. Step 1: Recall GraphQL syntax for required fields

   In GraphQL, to make a field required, you add ! after the type, not before the type or after the field name.

2. Step 2: Match the correct syntax

   The correct syntax is name: String! meaning the field name is a non-null string.

3. Final Answer:

   name: String! -> Option D

4. Quick Check:

   Required field syntax = type + ! after type [OK]

Hint: Put ! right after the type, never before field name [OK]

Common Mistakes:

• Placing ! before the type
• Adding ! after the field name
• Omitting ! for required fields

3. Given this GraphQL type definition:

type User {
  id: ID!
  email: String!
  phone: String
}

Which of these queries will cause an error if email is missing in the data?

medium

A. Query requesting only phone

B. Query requesting id and phone only

C. Query requesting id and email

D. Query requesting only id

Solution

1. Step 1: Identify required fields in the type

   The fields id and email are marked with !, so they must not be null or missing.

2. Step 2: Analyze queries requesting email

   If the data is missing email, any query requesting it will cause an error because it's required.

3. Final Answer:

   Query requesting id and email -> Option C

4. Quick Check:

   Requesting missing required field causes error = A [OK]

Hint: Queries asking for missing required fields cause errors [OK]

Common Mistakes:

• Assuming optional fields cause errors if missing
• Ignoring ! meaning required
• Thinking missing required fields return null

4. Consider this GraphQL schema snippet:

type Product {
  id: ID!
  name: String!
  description: String
}

Which change fixes the error when a query returns null for name?

medium

A. Add ! to description field

B. Remove ! from name field

C. Change id type to ID without !

D. Rename name field to title

Solution

1. Step 1: Understand the error cause

   The error occurs because name is required (String!) but the query returns null, violating the non-null rule.

2. Step 2: Fix by making name optional

   Removing ! from name allows it to be null, fixing the error.

3. Final Answer:

   Remove ! from name field -> Option B

4. Quick Check:

   Null returned for required field? Remove ! [OK]

Hint: If null causes error, remove ! to allow optional [OK]

Common Mistakes:

• Adding ! to optional fields instead of removing
• Changing unrelated fields
• Renaming fields without fixing null issue

5. You have this GraphQL input type:

input NewUserInput {
  username: String!
  email: String!
  phone: String
}

You want to ensure phone is also required but keep it optional for some mutations. How can you design this?

hard

A. Create two input types: one with phone: String! and one with phone: String

B. Add ! to phone in the existing input type

C. Remove ! from username and email

D. Make all fields optional by removing all !

Solution

1. Step 1: Understand requirement for conditional field requirement

   You want phone required in some cases but optional in others, so a single input type cannot express both.

2. Step 2: Use multiple input types for flexibility

   Creating two input types--one with phone: String! and one with phone: String--lets you choose which to use per mutation.

3. Final Answer:

   Create two input types: one with phone: String! and one with phone: String -> Option A

4. Quick Check:

   Use multiple input types for conditional required fields [OK]

Hint: Use separate input types to toggle required fields flexibly [OK]

Common Mistakes:

• Trying to toggle ! dynamically in one input type
• Removing required from always required fields
• Making all fields optional losing data integrity