Schema Design & Evolution

Decide on consumer count and trust. A recursive where input turns the schema into a query language: every combination becomes a supported contract, nobody can enumerate the access paths to index, and static cost scoring loses its grip.

Treat each Non-Null as a promise you can never withdraw without a client migration. Default to nullable, spend Non-Null only on values guaranteed by an object's identity, and make adding one a reviewed decision rather than a stylistic default.

Hard-fail only breaking edits with observed usage; require a named reviewer for the dangerous class and for breaking edits with credible zero-usage evidence; report nothing for safe additions. Make overrides possible but recorded, and treat the override rate as the gate's health metric.

Make deprecation a promise, not a label: a stated window, a named replacement, an owner and a date. The window comes from how long the oldest client you cannot force to upgrade survives in the field.

Yes. Object types refer to each other by name, so a schema is a graph and cycles — including a type referring to itself — are ordinary. What is finite is the document a caller writes, not the type graph.

Released GraphQL editions cannot express "exactly one of", so the usual shape is several nullable fields plus a runtime check. The alternatives are one schema field per case, or the draft @oneOf input marking where servers support it.

The type system cannot express "at least one of these". Non-null makes a filter mandatory on every call, breaking existing documents. The options are separate fields with a required anchor, a required argument on a new field, or a documented runtime check.