graphql

# GraphQL ## Purpose Design a GraphQL schema that models the domain rather than the database, and operate it without letting a single query take down the service. ## When to Use - Designing a GraphQL schema from scratch. - Diagnosing slow queries or N+1 resolver behavior. - Protecting a public GraphQL endpoint from expensive queries. - Splitting a schema across services with federation. ## Capabilities - Schema design: types, interfaces, unions, connections, nullability. - Resolver architecture and DataLoader batching. - Query cost analysis, depth limiting, and persisted queries. - Error handling that distinguishes partial failures from total ones. - Federation and schema composition. ## Inputs - The domain model and the client's actual query patterns. - The data sources behind each field. - Whether the endpoint is public (untrusted queries) or internal. ## Outputs - A schema with deliberate nullability and stable field names. - Resolvers that batch, with no N+1 on any documented query. - Cost limits and a persisted-query allow-list for public endpoints. ## Workflow 1. **Design for the client, not the tables** — The schema is a product surface. If it mirrors your database, you have built a slower REST API with worse caching. 2. **Get nullability right early** — A nullable field is a permanent client burden; a non-null field that later fails takes down the whole parent object. Non-null for genuine invariants only. 3. **Batch every relation** — Every resolver that f...