GraphQL API Development for Flexible and Efficient Data APIs

GraphQL is the better choice when: multiple clients (web, iOS, Android, partners) consume the same API and have different data needs; the frontend team changes data requirements frequently; you need real-time subscriptions alongside queries; or you're building a product platform where third-party developers query your data. REST is the better choice for simple CRUD services, public APIs where HTTP caching is critical, or teams without GraphQL experience where the learning curve outweighs the benefits.

Apollo Federation 2 composes multiple subgraph schemas into a single supergraph. Each subgraph owns its domain types and exposes @key-decorated entities. The Apollo Router (or Apollo Gateway) routes incoming queries to the correct subgraphs, fetches entity references via the @external and @requires directives, and assembles the response. Schema composition is validated in CI — the router only starts if the composed supergraph is valid.

Query depth limiting (max 7 levels), query complexity analysis (max score 1000, calculated per field), rate limiting on the HTTP layer via Redis, persisted queries (production clients can only run pre-approved queries), and introspection disabled in production. For large-scale APIs, we add APQ (Automatic Persisted Queries) to reduce payload size and Apollo Studio anomaly detection for unusual query patterns.

GraphQL subscriptions are WebSocket connections — stateful. A single server instance can hold thousands of subscriptions, but horizontal scaling requires routing subscription events to the correct server. We use Redis pub/sub: when an event occurs, the publishing service writes to Redis; every gateway instance subscribes to Redis and forwards the event to the correct WebSocket connection. This scales to hundreds of thousands of concurrent subscriptions.

The GraphQL spec does not cover file uploads. We use the multipart request spec (graphql-multipart-request-spec) — either via Apollo Server's built-in upload support or graphql-upload middleware. Files are streamed directly to S3 from the resolver without touching the application server disk. Alternatively, we implement a REST upload endpoint alongside GraphQL for large or frequent file uploads.

Field-level access control via custom directives (@auth, @requiresRole) that check JWT claims before returning PII fields. Data-subject request resolvers that anonymise or return all data for a given user ID. Query audit logging — every query is logged with the authenticated user ID and resolved fields. For EU deployments, the GraphQL gateway routes EU-resident entity queries to EU-region resolvers that enforce data-residency.

We use Apollo Server's RESTDataSource to wrap existing REST endpoints in GraphQL resolvers. The GraphQL schema is designed first based on client data needs, then resolvers delegate to REST. As backend services are updated, resolvers migrate from REST calls to direct database queries. This allows frontend teams to adopt GraphQL immediately while backend migration happens incrementally over weeks or months.