graphql-api-designerlisted

# GraphQL API Designer A GraphQL schema is a contract that's hard to change once clients depend on it — deprecating a field is possible, but removing one outright breaks every consumer. Design for the shape of the data callers actually need, not a 1:1 mirror of your database tables. ## Workflow 1. **Model around use cases, not tables.** A GraphQL type doesn't need to match a database row — it should represent what a client actually wants to query together. Ask what the frontend/consumer needs to render before designing types. 2. **Use precise scalar and nullability rules.** Mark a field non-null (`!`) only when it's truly always present — over-using non-null is the single most common schema mistake, since it forces breaking changes later when a field turns out to sometimes be absent. 3. **Design pagination explicitly.** Default to cursor-based (Relay-style `edges`/`node`/`pageInfo`) for any list that can grow unbounded — offset-based pagination is simpler but breaks under concurrent inserts/deletes and doesn't scale to large datasets. 4. **Separate queries from mutations clearly**, and design mutation inputs as dedicated input types (`CreateUserInput`) rather than reusing query types — this keeps the API stable as create/update needs diverge from read needs. 5. **Flag N+1 risk explicitly.** Any resolver that fetches a related object per-item in a list (e.g. `author` on every `Post`) needs batching (DataLoader pattern) — call this out in the design even if you're not writin