A GraphQL API Checklist

Questions to ask

Is the schema designed around client needs with clear names, descriptions and deliberate nullability? Do mutations use input and payload types with typed user errors? Are lists paginated with connections and maximum page sizes? Are N+1 queries solved with DataLoader? Is authorisation enforced where data is loaded? Are depth, cost and rate limits in place and errors masked? Are schema changes checked in CI with deprecation before removal? Are operations named and monitored?

The checklist

Use it in reviews.

[ ] schema designed for clients; descriptions on types and fields
[ ] deliberate nullability; enums for closed sets; input types for mutations
[ ] mutations return payloads with changed objects + typed userErrors
[ ] connection pagination with max page size
[ ] DataLoader per request; no N+1 in resolvers
[ ] authorisation in the data/business layer for every object
[ ] depth / cost / timeout / rate limits; aliases and batches counted
[ ] masked errors; introspection policy for production
[ ] schema checks in CI; @deprecated before removal; field usage tracked
[ ] named operations; tracing and metrics per operation

Measure per operation

Latency and error metrics broken down by operation name show which client queries need attention.

Quick check: Which belongs on a GraphQL API checklist?

• Authorisation only on root fields
• Unbounded lists for convenience
• Lists use cursor pagination with a maximum page size
• Removing fields without deprecation