Lovable prompt to build a GraphQL API
Lovable defaults to REST-shaped Supabase queries, so getting a real GraphQL endpoint means telling it exactly where the schema lives and how auth flows through resolvers. This prompt pins the API to one edge function, keeps row level security in charge of visibility, and adds a playground page so you can test queries inside the preview.
Last updated
Stand up a GraphQL API in this project as a single Supabase edge function named graphql, with GraphQL Yoga bundled into the function.
Schema: a {{resource}} type with id, name, status, and created_at, a paginated list query accepting limit, cursor, and a status filter, a single-record query by id, and mutations for create, update, and delete.
Resolvers: read and write through a Supabase client created from the caller's Authorization header so row level security still decides what each user can touch. Never use the service role key inside resolvers.
Errors: throw typed GraphQL errors with codes UNAUTHENTICATED, NOT_FOUND, and BAD_INPUT instead of generic 500s, and surface field-level validation messages for missing required inputs.
Frontend: add a small /playground page with a query editor textarea, a run button, and a formatted JSON result pane so I can exercise the endpoint without leaving the preview.
Hardening: handle CORS for the app origin only, and reject any query nested deeper than four levels to stop abusive queries.
Acceptance: the list query returns a cursor that fetches the next page, a mutation without a signed-in session comes back UNAUTHENTICATED, deleting a record owned by another user returns NOT_FOUND rather than confirming it exists, and the playground shows errors inline instead of crashing.Customize it
Runs in your browser. Nothing you type here is sent anywhere.
Stand up a GraphQL API in this project as a single Supabase edge function named graphql, with GraphQL Yoga bundled into the function. Schema: a users type with id, name, status, and created_at, a paginated list query accepting limit, cursor, and a status filter, a single-record query by id, and mutations for create, update, and delete. Resolvers: read and write through a Supabase client created from the caller's Authorization header so row level security still decides what each user can touch. Never use the service role key inside resolvers. Errors: throw typed GraphQL errors with codes UNAUTHENTICATED, NOT_FOUND, and BAD_INPUT instead of generic 500s, and surface field-level validation messages for missing required inputs. Frontend: add a small /playground page with a query editor textarea, a run button, and a formatted JSON result pane so I can exercise the endpoint without leaving the preview. Hardening: handle CORS for the app origin only, and reject any query nested deeper than four levels to stop abusive queries. Acceptance: the list query returns a cursor that fetches the next page, a mutation without a signed-in session comes back UNAUTHENTICATED, deleting a record owned by another user returns NOT_FOUND rather than confirming it exists, and the playground shows errors inline instead of crashing.
Same task in other tools
Questions about this prompt
Why route GraphQL through one edge function instead of Supabase's built-in pg_graphql?
A function you own lets you shape the schema, error codes, and depth limits, and Lovable can edit it like any other file. pg_graphql exposes the whole database shape, which is rarely what you want callers to see.
Can I add subscriptions to this API?
Edge functions are request-scoped, so long-lived GraphQL subscriptions do not fit. Ask Lovable for Supabase realtime channels on the underlying tables instead, and keep the GraphQL layer for queries and mutations.
Mutations work in the playground but return nothing from the app. Why?
The playground is probably sending your session token while the app call omits the Authorization header, so RLS filters results to zero rows. Have Lovable attach the Supabase session token to every GraphQL fetch.