Nullability & List Modifiers

## Nullable is the default, and `!` is the exception In GraphQL's type system every type is nullable until you say otherwise. Writing `title: String` in SDL declares a field whose value may be a string or may be `null`. Adding the exclamation mark — `title: String!` — wraps that type in the **Non-Null** type, and a Non-Null type has no null among its possible values. This is the opposite default from most statically typed languages candidates arrive from, and it is a deliberate choice by the specification: the permissive shape is the baseline, and strictness is opt-in one position at a time. The `!` is not a decoration, an annotation, or a validation attribute hung on the field. It is a **wrapping type** — one of the two the specification defines, the other being the list type written with square brackets. `String!` is not "the `String` type in strict mode"; it is a different type that wraps `String`. You can see this structurally in an introspection result, where a Non-Null appears as a type with `kind: NON_NULL` and `name: null`, whose `ofType` points at the named type inside it. That nesting is why type modifiers are read from the inside out, and why `[String!]!` is three types deep rather than one string type with two flags. ## Two sides of one modifier Where the modifier sits decides whose obligation it is. On an **output position** — a field of an object type or an interface — Non-Null is a promise the *server* makes to every caller: this key will appear in the response carrying a value that is not null. A typed client generator reads that promise and emits a non-optional property, which is the practical payoff: callers stop writing defensive null checks for that field. On an **input position** — a field argument, an input object field, or a variable definition — Non-Null is a requirement on the *client*: a value must be present, and the literal `null` is never acceptable there. That is checked before execution begins rather than inside a resolver. Same syntax, opposite direction of obligation. Interviewers probe this pair because candidates who have only ever consumed a schema tend to know the output half and have never thought about the input half. ## A job board, and what `!` does not promise Take a job-board graph whose `JobPosting` type has grown to 37 fields. A slice of it declares `id: ID!`, `title: String!`, `company: Company!`, `salaryMax: Int`, `closesAt: String` and `applicantCount: Int!`. Read the promises off it. Every posting has an `id`, a `title` and a `company`. `salaryMax` may be null, and that is meaningful information rather than an oversight: plenty of postings publish no maximum, and null is how the schema says "there is no value here". `closesAt` may be null because a posting can be open-ended. Now the limits, which are exactly where weak candidates over-claim: - **`!` is not "non-empty".** `title: String!` is fully satisfied by `""`. A field typed `[Skill!]!` is fully satisfied by `[]`. Non-emptiness is not expressible in the type system at all; it is a runtime concern. - **`!` is not "fresh" or "correct".** If `applicantCount: Int!` is served from a counter that lagged the last 90 seconds of applications, the response is stale — and completely valid against the schema. The type system constrains the shape of the value, never its truth. Saying this out loud is worth marks, because "it is `Int!`, so it must be right" is a real reasoning error in incident reviews. - **`!` is not a storage constraint.** Nothing forces the database behind the field to agree with it. The modifier describes the wire, and it is the server's job to make the wire true. ## When the promise cannot be kept If the code behind a Non-Null output field produces null, the server cannot serialize a null in that position — doing so would contradict the schema it published. Instead the field is treated as having errored, an entry appears in the response's `errors` list, and the null is pushed outward to the nearest position that permits one. The mechanics of that outward push are a subject of their own; the narrower point here is that **a Non-Null field has no "just send null" escape hatch.** Writing `!` chooses that consequence. ## Reading a type back to yourself A habit worth building for both interviews and code review: read a type aloud from the inside out, one modifier at a time. `String` — a string, or null. `String!` — a string, never null. `[String!]!` — a list, never null, whose elements are strings, never null. Each modifier you peel off describes exactly one position. Candidates who read the whole thing as one blob ("the strict string list") are the ones who get list variants wrong under pressure, because they never separated the promise about the container from the promise about what is inside it.