GraphQL API Development Services

Type definitions for your business domain: object types, input types, enums, interfaces, and unions designed to model business entities accurately rather than mirroring database table structure. Query definitions for all data retrieval operations, mutation definitions for create/update/delete operations, and subscription type definitions for real-time event streams. Interface types enable polymorphic queries that return different concrete types in a single request -- a notification feed that contains different object shapes per notification type, handled in a single query with fragments. Union types handle cases where a field may return meaningfully different types that don't share a common interface. Relay-compatible pagination patterns (Connection/Edge/Node) provide a consistent cursor-based pagination model that GraphQL clients like Relay and Apollo Client handle natively. Schema design review before resolver implementation using tools like graphql-inspector to catch structural problems while they're cheap to fix -- a naming inconsistency or circular type dependency discovered in schema review takes minutes to fix; the same issue discovered after resolvers are written and clients have integrated requires a breaking change or a migration path.

Resolver functions for every field in the schema -- implemented with separation between the resolver layer (responsible for GraphQL-to-service coordination) and the service layer (responsible for business logic), so that business rules can be tested independently of GraphQL mechanics and reused by REST endpoints or background jobs that share the same underlying operations. Context injection provides database connections (Prisma, TypeORM, Knex), the authenticated user object, and DataLoader instances to resolvers through GraphQL context rather than global state, enabling request-scoped access control and DataLoader instance-per-request batching. Error handling produces structured GraphQL errors with defined error codes and messages rather than unhandled promise rejections that propagate as generic server errors -- GraphQL's error handling model allows partial success (some fields resolved, some errored) with errors surfaced in the response errors array alongside available data. Resolver testing with mocked data sources validates resolver logic independently of database connectivity, enabling unit-level test coverage for every query, mutation, and subscription without a running database. Apollo Server plugins for request lifecycle hooks (request start, execution, field resolution) provide instrumentation points for request tracing, slow field detection, and security auditing.

DataLoader implementation for every resolver that fetches related data -- batching and caching database calls across resolver executions within a single GraphQL request. The N+1 problem is GraphQL's most common production performance failure: without DataLoader, resolving a list of 50 articles with their authors generates 51 database queries (one for the list, one per author). With DataLoader, those 50 author lookups batch into a single WHERE id IN (...) query and are cached for the duration of the request -- 2 queries total instead of 51. DataLoader instances are scoped per-request (not global) to prevent cross-request cache contamination in concurrent server environments. Query complexity analysis assigns a cost to each field and rejects queries whose total calculated cost exceeds a defined limit -- preventing a client from constructing a deeply nested query that generates unbounded database load. Depth limiting rejects queries nested beyond a configurable maximum depth (typically 7-10 levels) as a secondary defence. Persisted queries store approved query hashes server-side and reject arbitrary query strings from production clients -- the most effective defence against query abuse when client code is controlled, and a significant performance improvement since query parsing and validation are skipped for known queries.

JWT or session-based authentication validated in GraphQL context before resolvers execute -- a failed authentication check short-circuits the entire request before any resolver runs, preventing information leakage through partial resolution. Field-level authorisation using graphql-shield or custom directive-based authorization restricts which fields are visible to which client types: a public API consumer, a partner integration, and an internal admin client can share a schema definition while each seeing only the fields their role permits -- the admin client sees user.internalNotes, the public client gets a null or error for the same field. Role-based access control (RBAC) and attribute-based access control (ABAC) patterns implemented at the resolver layer mean that authorisation logic lives adjacent to the data access code rather than scattered across middleware. Error responses for unauthorised field access return structured FORBIDDEN errors in the GraphQL errors array for the specific field -- not a blanket 403 that fails the entire request and provides no signal about which part was unauthorised. Schema introspection disabled for production public endpoints to prevent schema discovery by unauthenticated callers; introspection available to authenticated admin clients via a separate context check.

Subscription implementation for real-time data delivery over WebSocket -- the mechanism that pushes updates to connected clients when data changes rather than requiring clients to poll. Apollo Server's subscription support uses graphql-ws over WebSocket (the current standard; legacy subscriptions-transport-ws is deprecated) with connection initialisation hooks for authentication -- the WebSocket handshake validates the client's token before the connection is accepted rather than establishing the connection and then rejecting subscription requests. PubSub implementation: Redis-backed graphql-redis-subscriptions for multi-instance production deployments where multiple server instances need to share subscription events; in-memory PubSub for single-instance deployments. Event publishing from mutations to subscription consumers uses async iterators filtered per-subscription -- a client subscribed to orderStatusUpdated(orderId: "123") receives events only for order 123, not all order status changes. Subscription filtering logic runs server-side so bandwidth is not wasted delivering events to clients that will discard them. Connection management handles WebSocket disconnections gracefully with client-side reconnection logic (Apollo Client's retry link) and server-side cleanup of stale subscriber registrations to prevent memory leaks in long-running subscription servers.

GraphQL Playground and Apollo Sandbox for interactive schema exploration, with authentication header injection configured so developers can test authenticated queries without leaving the documentation environment. Schema documentation written as SDL descriptions on every type and field and served via introspection -- so documentation is generated from the schema definition itself rather than maintained separately and left to drift. Apollo Federation 2 for organisations with multiple GraphQL services (products service, users service, orders service) that need to be composed into a single unified graph via an Apollo Router gateway -- product teams own and deploy their subgraph independently without coordinating schema changes through a central API team, while the gateway handles query planning and cross-service data joining at the gateway layer. Entity resolution (the @key directive and __resolveReference pattern) enables subgraphs to extend types owned by other subgraphs -- the users subgraph defines User and the orders subgraph extends it with order history, each service authoritative for its own fields. Schema versioning uses @deprecated annotations with replacement field guidance rather than version-bumping the entire schema for additive changes; breaking changes are published with a sunset date and migration guide so client teams have lead time to adapt.