v0 prompt to build a GraphQL API
v0 will happily scaffold a GraphQL layer, but only if the prompt pins where it lives and how it fails. This spec produces a graphql-yoga route handler with cursor pagination and typed errors, plus a playground page so you can run queries inside the preview before wiring a real client.
Last updated
Build a GraphQL API inside a Next.js App Router project, served from one route handler at app/api/graphql/route.ts using graphql-yoga. Schema: a {{resource}} type with id, name, status, and updatedAt, a paginated list query using cursor pagination (first, after) rather than offsets, a single-item query by id, and create, update, and delete mutations that return the mutated object. Resolvers read {{database}} through a db.ts helper so the data layer stays swappable. Validation: reject an empty name with a GraphQL error carrying extensions.code BAD_USER_INPUT, and return null with a NOT_FOUND code when an id does not exist instead of throwing. Add a query depth limit so nested selections cannot recurse unbounded, and disable introspection when NODE_ENV is production. Also generate a minimal /playground page in the same project: a textarea for the query, a variables field, a run button, and a pretty-printed JSON response panel using shadcn/ui Card and Tabs, so the API is exercisable inside the v0 preview without external tooling. Playground empty state: a preloaded example query for the paginated list. Playground error state: network failures render the raw error body in a red monospace block, never a blank panel. Acceptance: the example query returns rows in the preview, a create mutation followed by the list query shows the new item, and a malformed query comes back as a structured GraphQL error response, not a 500.Customize it
Runs in your browser. Nothing you type here is sent anywhere.
Build a GraphQL API inside a Next.js App Router project, served from one route handler at app/api/graphql/route.ts using graphql-yoga. Schema: a users type with id, name, status, and updatedAt, a paginated list query using cursor pagination (first, after) rather than offsets, a single-item query by id, and create, update, and delete mutations that return the mutated object. Resolvers read PostgreSQL through a db.ts helper so the data layer stays swappable. Validation: reject an empty name with a GraphQL error carrying extensions.code BAD_USER_INPUT, and return null with a NOT_FOUND code when an id does not exist instead of throwing. Add a query depth limit so nested selections cannot recurse unbounded, and disable introspection when NODE_ENV is production. Also generate a minimal /playground page in the same project: a textarea for the query, a variables field, a run button, and a pretty-printed JSON response panel using shadcn/ui Card and Tabs, so the API is exercisable inside the v0 preview without external tooling. Playground empty state: a preloaded example query for the paginated list. Playground error state: network failures render the raw error body in a red monospace block, never a blank panel. Acceptance: the example query returns rows in the preview, a create mutation followed by the list query shows the new item, and a malformed query comes back as a structured GraphQL error response, not a 500.
Same task in other tools
Questions about this prompt
Why ask for a playground page instead of just the API?
v0 previews render UI, not curl sessions, so a small query console is how you exercise the endpoint without leaving the browser. It also keeps v0 honest: if the playground returns rows, the resolvers are wired, not mocked.
How do I point the resolvers at my real database?
Everything goes through db.ts, so connect the Neon or Supabase integration in project settings, then ask v0 to implement the helper against it. Resolver signatures and the schema stay untouched, which is the point of the indirection.
The playground works but my external client gets errors. What happened?
Usually the route handler only accepts the exact request shape the playground sends. Ask v0 to handle both GET and POST on the handler and to add CORS headers for your client origin. Also remember introspection is off in production by design, so codegen tools need to run against a dev deployment.