GraphQL Explained: Over-fetching, Schema, N+1 Problem

How GraphQL fixes over- and under-fetching with one endpoint and client-chosen fields, how the schema works, the N+1 query problem and DataLoader, and when…

GraphQL: common questions

What is the N+1 problem in GraphQL?

Asking for a list of N items with a nested field runs one query for the list and then one per item for the nested field. Batching with DataLoader collects the IDs and fetches them in a single query, so it becomes 2 queries.

When should you not use GraphQL?

For simple apps with a few screens and similar data needs. REST is easier to cache with HTTP and CDNs, simpler to secure per endpoint, and familiar to every developer.

Related chapters

Keep learning

Overview

Lab: one GraphQL query, how many database queries? + events + Batch the venue lookups (DataLoader) database queries if each takes 5 ms

GraphQL: one endpoint, the client picks the fields

REST gives each thing its own address. That is simple, but one screen may need several requests and get back fields it never shows. GraphQL lets the screen ask for exactly what it needs in one go.

The problem with REST on a busy screen

Open the event page on the ticket site’s phone app. It shows the event name, the venue name and the three cheapest seats. With the REST API from the REST chapter , the app has to make three requests, one after the other, because it only learns the venue ID after the first answer arrives: GET /events/123 GET /venues/45 gets the venue name GET /events/123/tickets gets 800 seats, shows 3 Three round trips. On a slow phone network each can take 200–300 ms. This shows two problems, each with a name: A request returns much more than the screen uses. Here: 800 seats with every field, to show 3 prices. You could add a special REST endpoint just for this screen, but the website wants a different mix, the tablet another, and every new screen means another endpoint. Facebook hit exactly this in 2012 with its mobile news feed, built GraphQL to fix it, and made it public in 2015.

The idea: the client writes the shape it wants

A GraphQL API has one address, usually POST /graphql. Instead of choosing an endpoint, the client sends a small query listing the fields it wants. The answer comes back in the same shape: The phone app sends The server answers DY Patil One trip, and only the fields the screen shows. The website can send a different query to the same address and get a different shape. Nobody had to build a new endpoint.

The schema: the server’s list of what can be asked

The client can’t ask for just anything. The server publishes a schema: a list of types and the fields each has. It works like the REST endpoint list, but describes data instead of URLs: The ! means “never empty”. [Ticket!]! means “a list of tickets”. There are two kinds of request: a query reads (like GET) and a mutation changes something (like POST, PUT or DELETE). Booking seats is a mutation:

The trap: N+1 queries

Move the slider to ask for more events and watch the count:

What else GraphQL costs you

Caching is harder In REST, GET /events/123 is a fixed URL that browsers and CDNs can cache. In GraphQL every query is a POST to /graphql with a different body, so those easy caches don’t help. Permissions per field Anyone may see an event’s name. Only the venue manager may see who bought the tickets. With one endpoint you must check permission on each field, not each URL. Expensive queries A client can ask for events → tickets → buyers → their bookings → … in one request. Servers limit how deep or costly a query may be.

When to pick it

Pick GraphQL when many different clients need different slices of the same data and the product changes often: a big app with web, phone and tablet screens. For a simple app with a few screens, REST is easier to build, cache and secure. GraphQL is about what the client asks for. The third style is about how services call each other quickly: RPC. GitHub runs a public GraphQL API with node limits and a points-based rate limit. GitHub GraphQL in practice

More courses

Jobs, linked to lessons — Browse jobs where every requirement links to the chapter that teaches it. See how ready you are, how long the gap takes to close, and which listings look stale.
Match a job post to courses — Paste a job post. Each skill is matched to a track here and put in learning order, foundations first.
React from open source with patterns — Patterns extracted from Material UI, Radix, React Aria, React Hook Form, Redux Toolkit, TanStack, and Next.js — not slides about hooks.
Database in depth — How a query becomes work. Indexes, isolation, locks, and the plans that explain why a page is slow — not an ORM tour.
Build a real API with NestJS — One ticket-booking API, built in order: a plain Node server first, then NestJS modules, validation, a real database, and the features real clients lean on.
Microservices — Microservice patterns one diagram at a time: how to split a monolith, how services talk, and how data stays consistent without distributed transactions.
Kafka — A beginner-to-senior path through event logs, reliable delivery, production operations, and disaster recovery.
AI engineering for software engineers — Eight free reads, in order, for software engineers moving into AI: when to build an agent, how to build one, how to test it, and how the model works underneath.
Frontend system design — How a UI is sliced when it is a product, not a page: ownership of state, cache, routes, and what happens when the network lies.
TypeScript in depth — The type system as a design tool. Inference, narrowing, generics, and the errors that mean the model is wrong — not a catalog of utility types.
CSS in depth — See the box, then the page. Visual chapters from the box model through Flexbox surprises, Grid, selectors, and units, then backgrounds, shapes, and visual effects, each with a playground.
Accessibility — Foundations first (WCAG in plain words, semantic HTML, lists, alt text), then hands-on HTML labs, a full pass of WAI-ARIA 1.3, and a final fix-the-page challenge.
Docker — What an image is, why layers cache, and how containers find each other on a network.
Redis — Fifteen Redis patterns, one picture each: cache, session, lock, counter, rate limiter, queue, and when Redis is the wrong tool.
Kubernetes — Kubernetes from zero to operators: why it exists, Pods, Deployments and Services, then configuration, networking, storage, scheduling, scaling and security.