In GraphQL, why is making an output field Non-Null safe for clients but making it nullable again breaking?

## Who is the reader, and who is the writer Every nullability change question resolves the same way once you ask which party *consumes* the value. In the output position the server produces and the client consumes, so a change is safe for clients exactly when it shrinks the set of values they can receive, and breaking when it grows that set. Take a course-enrolment graph published to two mobile builds and a web app: ```graphql # before type Enrollment { id: ID! certificate: Certificate } # after — a tightening type Enrollment { id: ID! certificate: Certificate! } ``` Every client written against the *before* schema already contains a branch for `certificate == null`. After the tightening that branch becomes dead code, which is harmless. No document has to change, no field has to be reselected, and a typed client generator moves from a nullable type to a plain one — a narrowing that existing reading code still satisfies. That is the whole argument for calling the direction safe. ## Why the reverse breaks Now run it backwards. A team discovers that 1,463 historic enrolments were imported without a certificate record and proposes relaxing `Certificate!` to `Certificate`. Every client compiled against the promise has code shaped like `enrollment.certificate.issuedOn` with no guard, because the schema said a guard was unnecessary. The moment one response carries null there, that code faults. A client generator makes it worse in a useful way: the generated field type widens from `Certificate` to `Certificate | null`, which turns the change into a compile error in every downstream build — visible, but still a break that has to be scheduled across every deployed client, including the ones already in an app store. This asymmetry is why `!` is usually described as a one-way door. You can walk through it; you cannot walk back without a client migration. ## "Safe for clients" is not "safe" The direction that is safe for readers is a *tightening of the server's own obligations*, and that is where the real risk sits. Once `certificate: Certificate!` is published, the server has committed that every enrolment it will ever return has a certificate — across every tenant, every backfill, every new source of enrolment data, and every backend that might be unavailable when the field is resolved. Teams reach for `!` because it makes client code tidier, and then discover the promise was true of the data they had rather than of the domain. Ask instead: is the value guaranteed by the identity of the object, or merely by the current contents of a table? Only the first earns the wrapper. A useful practical rule: tighten output fields deliberately and rarely, and only when you can state the invariant in one sentence without the word "currently". ## Interface implementation follows the same direction The same asymmetry appears inside the type system itself. When an object type implements an interface, each field's type must be a valid sub-type of the interface's declaration, and a Non-Null of a type is a valid sub-type of that type. So if an interface declares: ```graphql interface Enrollable { certificate: Certificate } ``` an implementing object type may declare `certificate: Certificate!` — a stricter promise — but may not declare `certificate: Certificate` where the interface promised `Certificate!`. The reasoning is identical: a client that selects the field through the interface must be able to hold the value it was promised, whichever concrete type came back. Strengthening is always allowed; weakening is not. ## What to say about detection A schema diff will class the two edits differently — tightening as a change to watch, widening as outright breaking — but the classification is a property of the tooling, not of the specification. The specification defines what the types mean; nothing in it says a schema may not change. Everything about "breaking" is a statement about the clients you actually have, which is why teams pair a diff with evidence of what is really being selected before they let either edit through. ## The one-sentence version Outputs flow server to client, so removing a possible value (nullable to Non-Null) costs the client nothing and costs the server a permanent promise, while adding one back (Non-Null to nullable) costs the client every unguarded line it wrote on the strength of that promise.