What is the difference between a nullable and a non-nullable field in GraphQL?
Understand the difference between nullable and non-nullable GraphQL fields, the ! syntax, null propagation, and how to choose nullability wisely.
Expected Interview Answer
A nullable field may return null, while a non-nullable field (marked with a trailing ! in the schema) guarantees a non-null value and will error if the resolver ever returns null.
In the SDL, String is nullable but String! is non-nullable. Nullability is a contract: non-null fields promise clients the value is always present, but if a non-null resolver returns null, GraphQL propagates the null error up to the nearest nullable parent, potentially nulling out a whole branch of the response. Choosing nullability carefully balances client convenience against resilience — over-using ! can make partial failures wipe out large sections of data.
- Non-null fields let clients skip null checks safely
- Nullable fields allow partial results when data is missing or a resolver fails
- The ! contract is enforced by the type system and validated automatically
- Clear nullability improves generated client types
- Thoughtful nullability limits error blast radius
AI Mentor Explanation
A non-nullable field is like a mandatory eleven players on the team sheet — if even one is missing the match cannot legally start and the whole fixture is voided. A nullable field is like an optional twelfth man: nice to have, but the game proceeds fine without one. Mark too many roles as mandatory and one absence forfeits the entire match.
Step-by-Step Explanation
Step 1
Read the SDL syntax
A trailing ! makes a field or type non-nullable: name: String! must return a value, while name: String may return null.
Step 2
Understand the client contract
Non-null tells clients the value is always present, so generated types omit null and skip null checks.
Step 3
Learn null propagation
If a non-null resolver returns null, GraphQL sets the nearest nullable parent to null and reports an error, nulling a whole branch.
Step 4
Apply to lists carefully
[String!]! means a non-null list of non-null strings; each ! position controls a different nullability rule.
Step 5
Choose deliberately
Default to nullable for fields that can fail independently; use non-null only for values you can truly always provide.
What Interviewer Expects
- Knows the ! syntax marks non-nullable
- Explains null propagation to the nearest nullable parent
- Understands list nullability like [String!]!
- Can weigh resilience vs. convenience when choosing nullability
- Mentions that over-using ! enlarges error blast radius
Common Mistakes
- Thinking ! means 'required argument' in every context rather than non-null output
- Assuming a non-null resolver returning null just yields null instead of an error that propagates
- Confusing the two ! positions in [String!]!
- Making everything non-null, so one failure wipes out large response sections
Best Answer (HR Friendly)
“In GraphQL, a nullable field is allowed to come back empty, while a non-nullable field must always have a value or it counts as an error. You add an exclamation mark to make a field non-nullable, which tells clients they can always rely on it being there.”
Code Example
type User {
id: ID! # non-nullable: always present
name: String! # non-nullable: must return a value
bio: String # nullable: may be null
posts: [Post!]! # non-null list of non-null Post items
}const resolvers = {
User: {
// name is String! (non-null). If this returns null,
// GraphQL errors and nulls the nearest nullable parent.
name: (user) => user.name ?? null,
bio: (user) => user.bio, // String (nullable) - null is fine
},
};Follow-up Questions
- What happens to the response when a non-null field resolves to null?
- How do you interpret the two ! positions in [String!]!?
- When would you deliberately make a field nullable for resilience?
- How does nullability affect generated TypeScript client types?
- Does ! on an argument mean the same thing as ! on a return type?
MCQ Practice
1. What does the trailing ! in name: String! mean?
A trailing ! marks the field as non-nullable, meaning its resolver must return a non-null value or GraphQL raises an error.
2. If a non-null field's resolver returns null, what happens?
GraphQL cannot return null for a non-null field, so it errors and sets the nearest nullable ancestor to null, potentially nulling a whole branch.
3. What does [String!]! describe?
The inner ! makes each string non-null and the outer ! makes the list itself non-null, so both the list and every element must be present.
Flash Cards
How is a non-nullable field written in GraphQL? — With a trailing exclamation mark, e.g. name: String!; without it (String) the field is nullable.
What is null propagation? — If a non-null field resolves to null, GraphQL errors and sets the nearest nullable parent to null, nulling that whole branch.
What does [String!]! mean? — A non-null list of non-null strings — both the list and every element must be present.
Why not make every field non-null? — Over-using ! enlarges the error blast radius; one failing field can wipe out large sections of the response.
Continue Learning
Related Interview Questions
What is a GraphQL schema and what is the Schema Definition Language (SDL)?
medium
How does pagination work in GraphQL with cursor-based connections?
medium
How do you model expected business errors in a GraphQL schema rather than throwing them?
hard
Why can a single null collapse a whole GraphQL response, and how do you design against it?
hard