Design and Implement GraphQL APIs

Covers designing, securing, and consuming a GraphQL API, framed around the tension that its query flexibility is also its attack surface. Five patterns anchor the server side: schema design with intentional nullability (non-null fields always resolve or throw, Relay-style Connection/Edge/PageInfo pagination), DataLoader to batch and cache per-request database calls and prevent N+1 queries - 10 posts with authors goes from 11 queries to 2; Apollo Client normalized caching with typePolicies for custom merge and read behavior; graphql-codegen to generate typed operations from the schema so TypeScript never hand-types a query response; and errors modeled as union-type payloads (LoginSuccess | InvalidCredentials | AccountLocked) rather than thrown exceptions, since GraphQL errors are meant for unexpected failures, not expected ones.

npm install -D @graphql-codegen/cli
npm install -D @graphql-codegen/typescript

Use it for GraphQL schema and resolver design, Apollo Server or Client work, federation, subscriptions, DataLoader setup, or code generation - it explicitly says GraphQL isn't always the answer: for simple CRUD, REST is simpler, and for high-performance public APIs, REST with caching wins, so reach for this only when facing complex data relationships and diverse client needs. It routes adjacent concerns elsewhere: database query tuning to postgres-wizard, authentication to authentication-oauth, and general REST API design or WebSocket infrastructure to backend. It documents seven sharp edges, two at CRITICAL severity: resolvers issuing a separate database query per item, fixable only with a per-request DataLoader that returns results in the same order as the input IDs, and deeply nested or circular queries that can DoS a server without graphql-depth-limit and a complexity-cost rule. Five more at HIGH/MEDIUM: introspection left enabled in production hands an attacker the full schema map; relying only on @auth schema directives instead of resolver-level checks fails complex business rules like "can edit own posts or posts in groups they moderate"; authorizing a query but not its individual fields lets a viewer see another user's private email through an otherwise-public profile query; making fields non-null "for convenience" means one failing field nullifies its entire parent object up the response tree; treating a cheap user(id) query the same as an expensive nested users(first: 1000) query starves rate limiting of any real cost signal; and subscriptions that aren't cleaned up on disconnect accumulate as a memory leak.

Output is schema SDL (types, inputs, unions, Relay-style connections), resolver code wired to context-scoped DataLoaders, Apollo Client cache configuration and typed React hooks, and a codegen.ts config generating fully-typed query and mutation hooks. Nine automated validation checks flag defects at WARNING/INFO severity: introspection enabled in production, a direct database query in a resolver instead of a DataLoader, missing query-depth limiting, a resolver with no error handling, a JSON/Any schema type bypassing type safety, a mutation returning a bare type instead of an errors-carrying payload, a list field with no pagination arguments, a client query hook not handling its error state, and using refetch where a direct cache update would serve the UX better.

Names concrete server options (@apollo/server as the most popular, graphql-yoga for serverless, mercurius for Fastify with JIT), client options (@apollo/client for full caching and state, urql as a lighter alternative, graphql-request for simple uncached calls), and tooling (graphql-codegen for types, dataloader for batching, graphql-depth-limit/graphql-validation-complexity for DoS protection, graphql-ws for subscription transport). It delegates to four sibling skills: postgres-wizard for resolver-backing query optimization, authentication-oauth for GraphQL context auth, caching-strategies for response and DataLoader caching, and backend for WebSocket subscription infrastructure.

Backend and full-stack developers designing or hardening a GraphQL API - schema, resolvers, federation, or client integration - who need the N+1, DoS, authorization, and nullability pitfalls handled correctly, and who have already confirmed GraphQL is the right fit rather than a simpler REST API.