Problems GraphQL Solves
The bookshop's mobile home screen shows a book, its author and two reviews. With a typical REST API that takes three requests (/books/b1, /authors/a1, /books/b1/reviews), and each reply carries dozens of fields the screen never uses. On a slow phone network, both of those costs hurt.
The rule
One request, only the fields you need, from one evolving schema.
Each part of the rule answers a classic API pain:
- Under-fetching: one endpoint does not return enough, so the client makes follow-up requests, often one after another because it needs an ID from the first reply. GraphQL lets one query follow links: book, then its author, then its reviews.
- Over-fetching: an endpoint returns a fixed bundle, so every client downloads fields it ignores. In GraphQL each client selects its own fields.
- Versioning: REST teams often ship
/v2/when a response must change. A GraphQL schema grows instead: add new fields freely, mark old ones@deprecated, and remove them once no client asks for them. - A weak contract: GraphQL's schema is typed and can be queried by tools (this is called introspection), so editors can autocomplete fields and catch mistakes before a request is sent.
query {
book(id: "b1") {
title
author { name }
reviews(first: 2) { rating }
}
}That single query replaces the three REST calls, and returns only four kinds of values.
GraphQL is not free. The server is more complex to build, HTTP caching by URL works less naturally because most requests are POST to one endpoint, and a careless client can write a very expensive query. Teams accept those costs when many different clients need different slices of the same data.
The shortcut
When you meet an API problem, name the pain, then match it: too many trips → nest the fields in one query; too much data → select fewer fields; breaking changes → add and deprecate instead of versioning.
Count the trips
Three REST requests, the second waiting on an ID from the first. That is under-fetching.
The trap is claiming GraphQL makes the server faster. The server still fetches the same data; the savings are in round trips and payload size.
Drills
Answer fast — trust the rule.
A client must call /books/b1 and then /authors/a1 to show one card. What is this problem called?
A web page shows only a book's title, but the endpoint sends 30 fields. How does GraphQL help?
How does a GraphQL schema usually handle a field that is being replaced?
Which is a real cost of adopting GraphQL?
Remember
- One request, only the fields you need, from one evolving schema.
- Name the pain, then match it: trips → nest; size → select less; changes → deprecate.
- Trap: GraphQL cuts round trips and payload, not the server's own work.