GraphQL Fundamentals
Fast recall
Quick revision
Core answer
Whether you understand GraphQL as a client-driven query language with a typed schema that solves over/under-fetching, and can name what it costs (N+1, query complexity) vs. REST.
Saying 'GraphQL is better than REST' without naming the costs — N+1 via resolvers, query-complexity attacks, caching difficulty — or when REST is the right choice.
Frame GraphQL as solving over/under-fetching with a typed schema and a single endpoint, then name the costs the schema introduces — resolver N+1 (fixed with DataLoader), query-depth/complexity attacks (fixed with limits), and HTTP-level caching difficulty — so you can say when REST is the better choice.
Interview-ready guide
Interview answer
GraphQL is a query language for APIs where the client sends a single query describing the exact shape of data it wants and the server returns precisely that — no more, no less.
It exists because REST's fixed endpoints force a trade-off: one endpoint over-fetches fields you don't need, and to assemble a full view you often need multiple round trips, which is painful on mobile. GraphQL exposes one endpoint backed by a strongly-typed schema that's both the contract and the documentation, and each client requests exactly its view in one round trip.
The costs I'm honest about are on the server side: a naive resolver causes N+1 database calls — you fix that with DataLoader, which batches the per-item loads into one query — and the client's query power enables abuse, so in production you must enforce depth limits, cost analysis, and timeouts. You also lose REST's HTTP-level caching because it's a single POST endpoint.
So I'd use GraphQL as a BFF aggregating many services, but for a simple cacheable CRUD resource, REST is often the better choice.
GraphQL Fundamentals
Direct Answer
GraphQL is a query language and runtime for APIs, developed at Facebook, where the client sends a single query describing exactly the data shape it wants and the server returns precisely that — no more, no less. It exists because REST's fixed endpoints force a trade-off: one endpoint over-fetches (returns fields the client doesn't need) and another under-fetches (needs multiple round trips to assemble a view), especially painful on mobile. GraphQL collapses the view's data needs into one request, with a strong type system (schema) as the contract.
Common Mistakes & Pitfalls
Saying 'GraphQL is better than REST' without naming the costs — N+1 via resolvers, query-complexity attacks, caching difficulty — or when REST is the right choice.
Check your understanding
Answer these without looking back at the article.
- What is the N+1 problem in GraphQL resolvers, and how does DataLoader fix it?
- How do you protect a GraphQL server from malicious deeply-nested queries?
- Why is HTTP-level caching harder with GraphQL than REST, and how do persisted queries help?
- When is REST a better choice than GraphQL, and when is GraphQL clearly superior?
- What is the difference between a GraphQL query, mutation, and subscription?
Related interview prep categories
1Want a guided curriculum order?
These modules are also sequenced in our flagship backend interview track — open it when you prefer an ordered path instead of browsing by topic.