GraphQL API AI Prompts: Build Production APIs Faster in 2026

You are a GraphQL expert using Pothos (formerly GiraphQL) with TypeScript.

Build a type-safe GraphQL schema for a project management API:

Types to define:
- User, Organization, Project, Task, Comment, PageInfo, Connection types
- Task: id, title, description, status (enum), priority (enum), dueDate, assignedTo (User), project (Project), comments (CommentConnection), createdAt, updatedAt

Pothos setup:
- builder = new SchemaBuilder with: context type (user, organizationId, dataLoaders), plugins: [SimpleObjectsPlugin, RelayPlugin, ValidationPlugin, ScopeAuthPlugin]
- Relay plugin: automatic Connection and Edge types, cursor-based pagination on all list fields
- Enum types: TaskStatus (TODO, IN_PROGRESS, DONE, CANCELLED), Priority (LOW, MEDIUM, HIGH, CRITICAL)

Queries:
- task(id: ID!): Task — @auth(requires: AUTHENTICATED)
- tasks(filter: TaskFilterInput, first: Int, after: String): TaskConnection — paginated
- myTasks: [Task!]! — current user's assigned tasks

Mutations:
- createTask(input: CreateTaskInput!): CreateTaskPayload — returns task or errors array
- updateTask(id: ID!, input: UpdateTaskInput!): UpdateTaskPayload
- assignTask(taskId: ID!, userId: ID!): AssignTaskPayload

Output: schema builder setup, type definitions, query/mutation resolvers, and generated schema SDL.

You are a GraphQL performance expert specialising in DataLoader patterns.

Build a complete DataLoader setup for a GraphQL API to eliminate N+1 queries:

DataLoaders required (one per relationship):
- userLoader: batch load users by ID → Map<string, User>
- projectLoader: batch load projects by ID
- tasksByProjectLoader: batch load tasks by project ID → Map<string, Task[]>
- commentsByTaskLoader: batch load comments by task ID
- assignedTasksLoader: batch load tasks assigned to each user ID

Each DataLoader:
- Created per GraphQL request (in context factory — not global singletons)
- Batch function: single DB query with WHERE id = ANY($1) (PostgreSQL) or IN clause
- Cache: DataLoader's built-in per-request cache (deduplicates within one request)
- Max batch size: 100 (prevent overly large IN clauses)
- Error handling: return Error instance for missing IDs (DataLoader per-item error)

Context factory:
function createContext(req): Context {
  return {
    user: extractUserFromJWT(req),
    db: dbConnection,
    loaders: {
      user: new DataLoader(batchLoadUsers),
      project: new DataLoader(batchLoadProjects),
      tasksByProject: new DataLoader(batchLoadTasksByProject),
      // ...
    }
  }
}

Show: all DataLoader batch functions with SQL, context factory, and resolver usage in Task.assignedTo and Project.tasks fields.

CRITICAL: explain why DataLoaders must be created per-request, not per-server.

You are a GraphQL security architect.

Implement field-level authentication and authorization for a GraphQL API:

Authentication (Apollo Server context):
- Extract JWT from Authorization header in contextFunction
- Verify RS256 signature, check expiry
- Attach to context: { user: { id, organizationId, role } | null }
- Never throw in context creation — let resolvers decide what's public

Authorization approach — Schema Directives:
- @auth(requires: Role) directive on type fields
- @ownerOnly — resolver checks resource.userId === context.user.id
- @rateLimit(max: Int, window: String) — per-user field rate limiting

Directive implementation:
- mapSchema + MapperKind to wrap resolver functions at schema build time
- Auth directive: if context.user is null or wrong role → throw AuthenticationError (Apollo error code)
- Tenant isolation: every resolver that touches DB must filter by context.user.organizationId

Error handling:
- Distinguish: AuthenticationError (unauthenticated) vs ForbiddenError (wrong role)
- Never expose internal resolver errors — mask with "Internal server error" + log full error with request ID
- Extensions: include error code in { extensions: { code: 'UNAUTHENTICATED' } }

Output: directive definitions, mapSchema implementation, and 5 examples on type fields.

You are a GraphQL real-time expert.

Implement GraphQL subscriptions for real-time task updates:

Subscriptions:
- taskUpdated(projectId: ID!): Task — emits when any task in the project is updated
- taskAssigned(userId: ID!): Task — emits when a task is assigned to the user
- projectActivity(projectId: ID!): ActivityEvent — all project events stream

PubSub setup:
- graphql-redis-subscriptions with Redis for horizontal scaling (not in-memory PubSub)
- Channel naming: task:updated:{projectId}, task:assigned:{userId}
- Authorization in subscription resolver: verify user can access the projectId before subscribing

Publishing from mutations:
- After createTask mutation: pubsub.publish('task:updated:{projectId}', { taskUpdated: task })
- After assignTask mutation: pubsub.publish('task:assigned:{userId}', { taskAssigned: task })

WebSocket setup (Apollo Server + graphql-ws):
- wsServer: separate WebSocket server on same HTTP server
- Auth: extract JWT from connection params (not headers — WebSocket handshake headers are limited)
- Cleanup: on disconnect, close any open DB queries or subscriptions

Output: subscription type definitions, resolver with asyncIterator, Redis PubSub config, and wsServer setup.

You are an Apollo Federation expert.

Design a federated GraphQL schema across 3 microservices:

Subgraph 1 — users-service (owns User type):
- User @key(fields: "id"): id, email, name, role, createdAt
- Query: me, user(id: ID!), users(filter: UserFilter): [User!]!

Subgraph 2 — projects-service (owns Project, Task types):
- Project @key(fields: "id"): id, name, description, owner: User (reference)
- Task @key(fields: "id"): id, title, status, assignedTo: User (reference), project: Project
- Extends User @key(fields: "id") to add: assignedTasks: [Task!]! (defined in this subgraph)

Subgraph 3 — notifications-service (owns Notification type):
- Notification @key(fields: "id"): id, type, message, recipient: User (reference), read

Apollo Router (supergraph) config:
- Compose subgraph schemas with rover subgraph introspect
- JWT validation at router level (propagate as x-user-id, x-organization-id headers to subgraphs)
- Query plan caching
- Response caching with @cacheControl directives

Entity resolution:
- Each subgraph implements __resolveReference for its @key types
- Show how User is resolved across services without a shared DB

Output: all 3 subgraph schemas with @key, reference resolvers, and supergraph YAML config.

You are a GraphQL testing expert.

Write comprehensive tests for a GraphQL task API using Jest:

Test setup:
- ApolloServer in test mode: new ApolloServer({ schema }) + startStandaloneServer or executeOperation
- In-memory test context factory: mock DataLoaders, seed database via Prisma test client
- JWT factory: createTestToken(userId, role, organizationId)

Test operations (use gql tagged template literals):

Query tests:
1. task query: authenticated, returns full task with nested assignee (DataLoader called once — assert DB call count)
2. task query: returns null for other org's task (tenant isolation)
3. task query: unauthenticated → extensions.code === 'UNAUTHENTICATED'

Mutation tests:
4. createTask: valid input → task created in DB, subscription event published
5. createTask: validation failure → errors array with field-level messages (not a single error)
6. createTask: assignee from different org → FORBIDDEN error code

DataLoader test:
7. Fetch 5 tasks in one query → assert assignee DataLoader batch function called exactly once (spy on DB)

Output: Jest setup, reusable test helpers, and all 7 test cases with gql operations.

You are a GraphQL real-time systems engineer.

Add GraphQL subscriptions to an Apollo Server 4 + TypeScript API:

Transport: graphql-ws (WebSocket) — not the deprecated subscriptions-transport-ws
Schema additions:
  type Subscription {
    taskUpdated(projectId: ID!): TaskUpdatedPayload!
    commentAdded(taskId: ID!): Comment!
    userPresence(projectId: ID!): UserPresencePayload!
  }

PubSub: Redis-based (graphql-redis-subscriptions) for horizontal scaling — not in-memory PubSub
Authentication on subscription: verify JWT in ConnectionParams (passed on WebSocket connect), attach user to context
Subscription resolvers:
  - taskUpdated: filter pubsub events by projectId, verify user has access to that project
  - commentAdded: DataLoader batch for each emitted comment (don't fetch in subscription resolver)
  - userPresence: track connected users per project in Redis, broadcast join/leave events

Publishing: from REST mutation resolver AND from external service via Redis pub/sub
Apollo Studio support: configure subscriptions endpoint separately from HTTP endpoint

Output: subscription type definitions, resolver implementations, Redis PubSub setup, WebSocket server configuration, and client-side Apollo Client subscription hook in React.

You are a GraphQL federation architect.

Design a federated GraphQL architecture for a microservices system:

Subgraphs:
- users-service: User type (owner)
- tasks-service: Task type, extends User with tasks field
- notifications-service: Notification type, extends User with notifications field

Each subgraph uses Pothos with the Federation plugin:
- users-service: @key(fields: "id") on User, resolveReference implementation
- tasks-service: @extends User, @external id field, @requires for user.organizationId
- notifications-service: @extends User

Apollo Router configuration:
- Supergraph schema: compose with rover CLI in CI
- Query planning: router logs query plans in development
- Authorization: JWT verification in router (not per-subgraph) using Rhai script
- Rate limiting: per-operation rate limiting in router config (100/min default, 10/min for expensive operations)
- Persisted queries: register known query hashes, reject unknown queries in production

Local development: rover dev for hot-reloading subgraph composition

Output: Pothos federation setup for each subgraph, Apollo Router config YAML, rover composition command, and CI pipeline step for supergraph validation.

Context for all GraphQL prompts in this session:
- Language: TypeScript 5.4, strict mode
- Schema: Code-first with Pothos (NOT SDL-first in TypeScript projects)
- Server: GraphQL Yoga 5 OR Apollo Server 4 (specify which)
- DataLoader: MANDATORY on every resolver that returns a related entity
  Every field resolving a relationship must use a DataLoader — no exceptions
  Never write a resolver that calls db.findById() or db.findMany() directly without DataLoader
- Authorization: graphql-shield for field and type-level rules
  Never put auth logic inside individual resolver functions
- Security: depth limiting (max 10 levels), query complexity analysis (max 1000 points)
- Testing: graphql-request for full operation tests (NOT resolver unit tests)