graphql

# GraphQL Standards > Source: [GraphQL Best Practices](https://graphql.org/learn/best-practices/) · [Apollo Naming Conventions](https://www.apollographql.com/docs/graphos/schema-design/guides/naming-conventions) · [GraphQL Schema Design](https://graphql.org/learn/schema-design/) ## Priority: P0 — Schema Correctness ### Nullability The GraphQL spec makes every field nullable by default. A wrong `!` is not just inaccurate — when a non-null field resolver returns `null`, GraphQL propagates the null **upward** through the response tree, wiping out the nearest nullable parent. One bad guarantee can null out an entire object from the client's response ([graphql.org](https://graphql.org/learn/schema-design/#nullability)). - Mark a field non-null (`!`) only when the server can **guarantee** it will never be null — not just "usually non-null". - Mutation payload root fields (`user`, `order`) must be nullable — the mutation may fail and return errors instead of data. - List elements and the list itself have separate nullability: `[User!]!` means a non-null list of non-null users. - `ID!` is always non-null — if you have an ID, it exists. ### Scalars & Custom Types - Use built-in scalars: `String`, `Int`, `Float`, `Boolean`, `ID`. - Add custom scalars for domain types: `DateTime`, `Date`, `URL`, `EmailAddress`, `JSON`. - `DON'T` use `String` for dates, emails, or URLs — custom scalars carry semantic meaning, enable server-side validation, and surface intent in generated client ty...