Cursor prompt to build a GraphQL API
Point Cursor at your repo with this prompt and it wires up a GraphQL schema, relay-style paginated connections, and mutations that return userErrors instead of throwing. It also forces dataloaders on nested fields and a test that counts executed queries, so the classic N+1 resolver problem gets caught before you ship it.
Last updated
Add a GraphQL API to this codebase in {{language}}. Define a schema with a {{resource}} type, queries for a single item by id and a paginated list using cursor-based connections (edges, nodes, pageInfo with hasNextPage and endCursor), and mutations for create, update, and delete that return the affected object plus a userErrors array instead of throwing on validation failures. Back the resolvers with {{database}} and add a dataloader for any nested field that would otherwise trigger N+1 queries. Reject queries deeper than 6 levels and cap the first argument at 100. Enable the playground only outside production. Write resolver tests that assert the batching actually happens by counting executed queries, run them, and summarize the schema and resolver files you touched.Customize it
Runs in your browser. Nothing you type here is sent anywhere.
Add a GraphQL API to this codebase in TypeScript. Define a schema with a users type, queries for a single item by id and a paginated list using cursor-based connections (edges, nodes, pageInfo with hasNextPage and endCursor), and mutations for create, update, and delete that return the affected object plus a userErrors array instead of throwing on validation failures. Back the resolvers with PostgreSQL and add a dataloader for any nested field that would otherwise trigger N+1 queries. Reject queries deeper than 6 levels and cap the first argument at 100. Enable the playground only outside production. Write resolver tests that assert the batching actually happens by counting executed queries, run them, and summarize the schema and resolver files you touched.
Same task in other tools
Questions about this prompt
Will this work with Apollo Server, Yoga, or code-first tools like Pothos?
Yes, but name the one you use or have the agent inspect package.json before writing anything. Schema-first and code-first setups produce very different files, and Cursor commits to whichever pattern it sees first, so a wrong guess means a large rewrite.
How do I verify the dataloader claim instead of trusting it?
The prompt asks for a test that counts queries executed during a nested request. Check that the test asserts a specific number, then temporarily remove the loader and confirm the count jumps. If it stays flat, the loader is not actually wired into the resolver path.
Cursor added depth limiting but my clients legitimately need deeper queries.
Raise the number in the prompt from 6 to whatever your deepest real query needs, and keep the cap on list sizes. Dropping the limit entirely reopens the door to abusive nested queries, so measure production traffic and set the ceiling just above it.