GraphQL
GraphQL is a query language for APIs that lets clients request exactly the data they need in a single request, using a strongly-typed schema to define available operations and data shapes.
GraphQL replaces multiple REST endpoints with a single endpoint where clients specify exactly what data they want. Instead of GET /users/42 returning a fixed shape, you write a query asking for specific fields — even across related resources in one request. The server has a strongly-typed schema defining all available types, fields, and relationships. This eliminates over-fetching (getting too much data) and under-fetching (needing multiple requests). It supports mutations for writes and subscriptions for real-time updates via WebSocket.
Strengths
- Eliminates over-fetching and under-fetching — clients get exactly the data they request
- Single request can traverse complex object graphs, replacing multiple REST round-trips
- Strongly-typed schema serves as living documentation and enables powerful developer tooling
- Introspection allows clients to discover available types, fields, and operations at runtime
- Frontend teams can iterate on data requirements without backend changes
- Federation enables composing multiple microservices into a unified API graph
Weaknesses
- HTTP caching is effectively broken — single POST endpoint prevents URL-based CDN caching
- N+1 query problem requires DataLoader or equivalent batching to avoid performance disasters
- Vulnerable to query complexity attacks — malicious deeply-nested or broad queries can overwhelm servers
- File uploads are not natively supported and require multipart form workarounds
- Server-side complexity is higher — resolvers, schema stitching, authorization per field
- Rate limiting is harder — queries vary wildly in cost, making per-request limits inadequate
Technical Profile
Latency Profile
Single GraphQL queries can replace 3-10 REST round-trips, reducing total latency for complex views from 500-2000ms to 100-300ms. However, individual query processing is heavier than a single REST endpoint due to parsing, validation, and resolver execution. Without DataLoader, N+1 queries can cause latency to explode linearly with result set size. Subscriptions add real-time capability with WebSocket latency (sub-millisecond for data push).
Payload Format
JSON
Browser Support
Yes
Streaming Support
Server-sent only
Schema Enforcement
Required
Ideal Use Cases
- Mobile applications needing minimal data transfer over constrained networks
- Applications with complex, deeply nested data relationships (social networks, e-commerce catalogs)
- Multi-platform products where web, mobile, and TV clients need different data shapes from the same API
- Internal APIs where frontend teams need autonomy to iterate on data requirements
- Microservice aggregation where a unified API layer composes data from multiple backend services
Real-World Examples
GraphQL API (v4) replaced their REST API for flexible repository, issue, and pull request queries — clients reduced payload sizes by 10x for common operations
Storefront API uses GraphQL to let merchants and app developers query product catalogs, collections, and checkout data with exact field selection
Uses GraphQL internally to aggregate data from hundreds of microservices into a unified API layer, reducing mobile app load times significantly
Uses GraphQL for their web and mobile clients to compose complex timeline views from multiple backend services in a single query
Adopted GraphQL for their checkout experience, reducing the number of API calls per page from 30+ REST requests to a single GraphQL query
Likely Follow-Up Questions
- How would you prevent a malicious client from sending an extremely expensive GraphQL query that crashes your server?
- Explain the N+1 problem in GraphQL and how DataLoader solves it at the resolver level.
- How does Apollo Federation work, and how does it compare to schema stitching for composing microservice APIs?
- How would you implement caching for a GraphQL API, given that HTTP-level caching doesn't work with POST requests?
- When would you choose REST over GraphQL, even for a complex application with diverse client needs?
Related Concepts
Source: editorial — Synthesized from the GraphQL specification, Apollo documentation, and engineering blogs from GitHub, Shopify, Airbnb, and PayPal on their GraphQL adoption journeys.