How GraphQL Works
IntermediateGraphQL is a query language for APIs where the client asks for exactly the data it needs — no more, no less — from a single endpoint. Instead of many REST URLs, a GraphQL server exposes one endpoint and a typed schema describing what can be queried. Clients send a query shaped like the response they want, and resolver functions on the server fetch each field. This eliminates over- and under-fetching, at the cost of new concerns like query complexity and caching.
Think of GraphQL as ordering exactly what you want
A REST API is like a fixed-menu restaurant: each dish (endpoint) comes with set sides, so you often get more than you want (over-fetching) or must order several dishes to make a meal (under-fetching). GraphQL is à la carte: you write down precisely the items and portions you want on one order form, and the kitchen (resolvers) assembles exactly that plate — one trip, no waste.
Step by Step
Key Concepts
Schema and Types
A strongly-typed description of everything the API can return. It is self-documenting and enables tooling like autocompletion and validation before a query even runs.
Resolver
A function that produces the value for one field. Resolvers compose into a tree that mirrors the query, each responsible for fetching or computing its slice of data.
Over- and Under-fetching
REST endpoints often return too much data (over-fetching) or too little, forcing multiple calls (under-fetching). GraphQL fixes both by letting the client request exactly the fields it needs.
The N+1 Problem in GraphQL
Resolving a list where each item triggers its own query. A DataLoader batches and caches these per request into a single query, which is essential for performant GraphQL.
Key Facts
- GraphQL uses a single endpoint and (usually) HTTP POST, which makes HTTP-level caching harder than REST GET URLs — persisted queries and CDNs help.
- A malicious or careless deeply-nested query can be expensive; production servers add query depth/complexity limits and timeouts.
- GraphQL and REST are not mutually exclusive — many systems expose GraphQL for flexible client reads and REST for simple, cacheable public endpoints.
Real-World Applications
Mobile and multi-client apps
A mobile app on a slow network can request just the few fields it shows, avoiding the bloated payloads of a one-size-fits-all REST endpoint — fewer bytes, fewer round trips.
Aggregating microservices
A GraphQL gateway can stitch data from several backend services into one graph, so clients make a single query instead of orchestrating many REST calls themselves.
Frequently Asked Questions
What is the difference between GraphQL and REST?
REST exposes many endpoints, each returning a fixed shape, which often causes over- or under-fetching. GraphQL exposes one endpoint and a typed schema; the client asks for exactly the fields it needs in a single query. REST is simpler and more cacheable; GraphQL is more flexible for varied clients.
What is a resolver in GraphQL?
A resolver is a server-side function that returns the value for a single field in the schema. When a query arrives, the server calls resolvers field by field, composing a tree that mirrors the query, with each resolver fetching or computing its part of the data.
Does GraphQL have an N+1 problem?
Yes — resolving a list can naively trigger one database query per item. The standard fix is a DataLoader, which batches the individual loads made during one request into a single query and caches them, keeping GraphQL efficient.
When should I use GraphQL over REST?
Choose GraphQL when clients need flexible, precise data (mobile apps, complex UIs), when you want to aggregate several services into one graph, or to avoid maintaining many bespoke endpoints. Stick with REST for simple, highly cacheable, public APIs where fixed responses are fine.