If you've built APIs using REST, you've probably run into its limitations. A mobile app needs just a user's name and avatar, but the /users/123 endpoint returns 30 fields. Or worse, you need data from three different endpoints to render a single screen, turning one user action into a waterfall of network requests.

GraphQL was created to solve these problems. But calling it "just a better REST" misses the point. GraphQL represents a fundamentally different way of thinking about API design, where the client, not the server, decides what data it needs.

In this chapter, we'll go beyond the basics. We'll explore how GraphQL actually works under the hood, how resolvers execute queries, common pitfalls like the N+1 problem, and when GraphQL is (and isn't) the right choice.

1. The Problem GraphQL Solves