Bolt prompt to build a GraphQL API
Bolt runs a real Node process in the browser tab, so a GraphQL server with a live GraphiQL playground boots directly in the preview pane. This prompt yields an SDL-first API with pagination caps, typed errors, and all data access isolated in a single store file, which keeps the later swap to a hosted database contained.
Last updated
Create a Node project running GraphQL Yoga so the server starts inside Bolt's WebContainer and the preview pane serves the GraphiQL playground at /graphql.
Schema, SDL-first in schema.graphql: a {{resource}} type with id, name, status, and createdAt. Queries: a paginated list taking limit, offset, and an optional status filter, plus a single fetch by id. Mutations: create, update, and delete for {{resource}}, each returning the affected record, delete included, not a boolean.
Resolvers live in src/resolvers.ts, one file, no codegen for v1. Back them with an in-memory array seeded with 12 records so the playground is useful immediately, but isolate every read and write in src/store.ts so I can swap in {{database}} later without touching a resolver.
Rules:
- Reject an empty name with a GraphQLError carrying extensions.code BAD_USER_INPUT.
- Clamp limit to 50 silently.
- Unknown id: null from the single query, a NOT_FOUND error from mutations.
Add GET /healthz returning { ok: true } outside GraphQL, and print the playground URL to the terminal on boot.
Dependencies: graphql and graphql-yoga only, no Apollo, no subscriptions, nothing with native bindings since WebContainers cannot compile them.
Acceptance: from GraphiQL in the preview I can create a record, page through the list with offset, filter by status, update a status, delete the record, and get NOT_FOUND when deleting it a second time.Customize it
Runs in your browser. Nothing you type here is sent anywhere.
Create a Node project running GraphQL Yoga so the server starts inside Bolt's WebContainer and the preview pane serves the GraphiQL playground at /graphql.
Schema, SDL-first in schema.graphql: a users type with id, name, status, and createdAt. Queries: a paginated list taking limit, offset, and an optional status filter, plus a single fetch by id. Mutations: create, update, and delete for users, each returning the affected record, delete included, not a boolean.
Resolvers live in src/resolvers.ts, one file, no codegen for v1. Back them with an in-memory array seeded with 12 records so the playground is useful immediately, but isolate every read and write in src/store.ts so I can swap in PostgreSQL later without touching a resolver.
Rules:
- Reject an empty name with a GraphQLError carrying extensions.code BAD_USER_INPUT.
- Clamp limit to 50 silently.
- Unknown id: null from the single query, a NOT_FOUND error from mutations.
Add GET /healthz returning { ok: true } outside GraphQL, and print the playground URL to the terminal on boot.
Dependencies: graphql and graphql-yoga only, no Apollo, no subscriptions, nothing with native bindings since WebContainers cannot compile them.
Acceptance: from GraphiQL in the preview I can create a record, page through the list with offset, filter by status, update a status, delete the record, and get NOT_FOUND when deleting it a second time.Same task in other tools
Questions about this prompt
Why GraphQL Yoga instead of Apollo Server here?
Yoga has a small dependency tree of pure JavaScript, which matters because Bolt's WebContainer cannot compile native modules. Apollo works too, but Yoga installs faster in the preview and ships GraphiQL by default, so the prompt pins it to keep boot time short and the playground free.
How do I point the resolvers at a real database?
All reads and writes go through src/store.ts by design. Connect Supabase from Bolt's integration menu, then ask it to reimplement the store functions with supabase-js queries while leaving resolvers untouched. If resolvers start importing the client directly, tell it to route everything back through the store.
The playground loads but every mutation returns INTERNAL_SERVER_ERROR. Where do I look?
Open Bolt's terminal. Yoga prints the underlying stack trace there even when the client only sees a masked error. The usual culprits are a resolver missing from the map after a schema edit, or the seed running after the server starts, so check boot order in the entry file.