# GraphQL Clients (Apollo)

You can write a GraphQL query in five minutes. Then you wire it into a real app and the questions start: where does the response live, why does one component update when another runs a mutation, and how do you stop the same data being fetched four times? A raw `fetch` won't answer any of that. Apollo Client does, and this guide is about the model that makes it work.

The relief here is that once you understand Apollo's **normalized cache**, most of the busywork of front-end data fetching disappears. You stop hand-managing loading flags, stale lists, and duplicated requests, because the cache does it for you. The cost is a new mental model you have to actually hold in your head, and a few new ways to get burned.

## How to read this

Read the phases in order. Phase 1 builds the mental model: what Apollo Client is, why a cache sits at its center, and how that differs from thinking in REST endpoints. Phase 2 is the everyday work: writing queries and mutations with hooks, and keeping the cache accurate after a write. Phase 3 is production reality: the gotchas that bite, from cache misses to refetch storms.

If you've never written a GraphQL query at all, skim [GraphQL Explained](/guides/graphql-explained) first, then come back. If REST is your only reference point, [REST APIs Explained](/guides/rest-apis-explained) gives you the contrast this guide keeps drawing on.

## The phases

1. [The cache is the point](01-the-cache-is-the-point.md) - what Apollo Client actually is, and why a normalized cache changes everything
2. [Queries and mutations in real components](02-queries-and-mutations.md) - the hooks you use daily, and updating the cache after a write
3. [When the cache lies to you](03-production-reality.md) - cache misses, refetch storms, and the tradeoffs you signed up for