What this prompt does
This prompt asks the AI to design a production GraphQL API for a [domain] using [framework]. It builds a schema with [types], query resolvers with Relay cursor pagination, validated mutations, DataLoader to kill N+1 queries, subscriptions for [realtime_events], custom scalars ([custom_scalars]), authorization directives, custom error codes, federation across [federated_services], and persisted queries — plus a schema-first approach, resolver testing strategy, and query complexity limiting.
The structure works because GraphQL's flexibility is also its trap: without DataLoader you get N+1 explosions, and without complexity limits a single query can take down your server. Defining [types] gives the schema its shape, and [realtime_events] decides which subscriptions exist. [framework] (like Apollo Server with TypeScript) determines the resolver and DataLoader idioms, while [federated_services] shapes how the graph is split across teams. The emphasis on persisted queries and complexity limiting is what makes the API safe to expose.
When to use it
- You're putting a GraphQL layer over existing data and need resolvers that survive real traffic
- You're fighting N+1 queries and need a DataLoader strategy designed in from the start
- You need Relay-style cursor pagination done correctly
- You want subscriptions for
[realtime_events]without guessing the transport - You're federating a graph across
[federated_services]and need the boundaries defined - You need query complexity limiting and persisted queries before exposing the API publicly
Example output
Expect a schema definition for [types], resolver implementations with DataLoader batching, a Relay connection setup for pagination, mutation resolvers with input validation, subscription resolvers for [realtime_events], custom scalar definitions, auth directive usage, and a federation plan for [federated_services]. It typically closes with a resolver testing approach and a complexity-limiting configuration.
Pro tips
- Define
[types]and their relationships clearly; ambiguous types produce resolvers that fetch too much or too little - Insist on DataLoader for every relationship; N+1 queries are the number-one GraphQL performance killer
- Match
[framework]to your stack so the resolver and DataLoader code is idiomatic, not pseudocode - Always include query complexity limiting before going public — without it, one deep nested query can exhaust your server
- Use persisted queries to lock down which operations clients can run, which also trims payload size
- For
[realtime_events], confirm your transport (WebSocket subscriptions need a compatible client and server setup)
