Meaning
GraphQL is a query language and server-side runtime for APIs that allows clients to request exactly the data they need and nothing more. It addresses the over-fetching and under-fetching problems common in REST APIs by giving clients control over the shape of responses. Developers reach for GraphQL when building APIs consumed by multiple clients with differing data needs or when network efficiency matters.
Primary Function
API design
Communicative Purpose
Enables precise, client-driven data fetching through a single endpoint with a typed schema.
Pattern
define schema → write resolvers → client sends query → server returns exactly requested fields
Função primária
API design
Propósito comunicativo
Enables precise, client-driven data fetching through a single endpoint with a typed schema.
Situações de gatilho
API design: building APIs consumed by web, mobile, and third-party clients with overlapping but distinct data needs; API design: replacing multiple REST endpoints with a single queryable endpoint; Frontend development: reducing over-fetching in mobile apps with limited bandwidth
Contextos
API gateways, microservices, mobile backends, BFF (Backend for Frontend) patterns, Apollo ecosystem, Hasura, GraphQL Yoga
Padrão
define schema → write resolvers → client sends query → server returns exactly requested fields
Colocados típicos
- schema definition language (SDL)
- resolvers
- queries
- mutations
- subscriptions
- Apollo Client/Server
- GraphQL Yoga
- type system
- fragments
- directives
Substituições comuns
- REST APIs: simpler but suffers from over-fetching
- gRPC: better for service-to-service but less flexible for clients
- JSON-RPC: lighter weight but no schema introspection
Erros comuns
N+1 query problem: resolvers fetching data per item without batching → causes severe performance degradation; Missing pagination on list fields: returning unbounded arrays → memory exhaustion on large datasets; Exposing internal fields without authorization: trusting schema-level access → security vulnerabilities; Not using fragments for shared selections: duplicating field selections → maintenance burden; Treating GraphQL as a database query language: writing complex joins in resolvers → bypasses caching and N+1 protections
Similar / contraste
REST: resource-oriented with multiple endpoints vs GraphQL's single endpoint with queryable schema; gRPC: schema-driven but binary protocol vs GraphQL's text-based JSON; OData: similar query capabilities but Microsoft-specific vs GraphQL's ecosystem-agnostic
Interferências
Coming from REST: may default to URL-based resource design — GraphQL uses a single endpoint with query strings in the request body; Coming from SQL: may write complex joins directly in resolvers — GraphQL resolvers should delegate to data loaders to avoid N+1 queries
Família do chunk
- REST
- gRPC
- OData
- JSON-RPC
- Falcor
- API schema design
Nuance
When NOT to use: simple CRUD apps with one client type where REST suffices; Performance: requires DataLoader or batching to avoid N+1 queries, and persisted queries for high-traffic endpoints; Boundary conditions: file uploads need separate handling (multipart spec), and real-time needs subscriptions or separate WebSocket setup
Efeito pragmático
Reduces network roundtrips by letting clients compose multi-resource requests in one call, eliminates versioning churn since clients request only fields they need, and provides a self-documenting schema that serves as living API documentation.
Dica de memória
GraphQL: like a restaurant where you build your own plate from a menu instead of ordering fixed combo meals — you get exactly what you want, no more, no less.
Upgrade path
GraphQL federation, persisted operations, DataLoader batching patterns, subscription-based real-time APIs
Log in to save chunks.