What is GraphQL

What it is

GraphQL sits over your data sources and answers precisely-shaped queries against a typed schema. Clients request the exact fields and relationships they need in one round trip, and the schema is self-documenting and introspectable.

• One endpoint, precise queries — no over- or under-fetching
• Strongly typed, introspectable, self-documenting schema
• Great for aggregating data from multiple sources

When we reach for it

GraphQL earns its keep when clients have varied data needs, when you aggregate several backends behind one API, or when frontend and backend teams iterate independently. Mobile and complex dashboards benefit most from asking for only what they render.

Trade-offs

It shifts complexity to the server: HTTP caching is harder than with REST, you need query-cost limits to prevent abuse, and naive resolvers cause N+1 database queries (solved with batching/dataloaders). For simple, uniform APIs, REST is often the lighter choice.

Why it matters

GraphQL is a query language and runtime for APIs, developed by Meta, that lets clients request exactly the data they need in a single request — no more, no less. It matters because it solves two chronic problems with traditional REST APIs: over-fetching (endpoints returning more data than the client needs) and under-fetching (needing several requests to assemble one screen's data). By exposing a single, strongly-typed endpoint where the client specifies its needs precisely, GraphQL makes front-end data-fetching efficient and flexible, which is why it is popular for complex applications and APIs serving many different clients.

• A query language for APIs where clients request exactly the data they need
• Solves REST's over-fetching and under-fetching problems
• A single, strongly-typed endpoint serving precise, flexible queries

Key characteristics

A GraphQL API is defined by a strongly-typed schema describing all the data and operations available; clients send queries specifying the exact fields they want, and the server returns precisely that shape in one response. This gives clients flexibility and eliminates round-trips, and the schema doubles as documentation and enables great tooling. The trade-offs are real: caching is harder than REST's simple URL-based caching, a naive implementation can allow expensive queries (needing depth/complexity limits), and the server-side setup (resolvers, the N+1 query problem) is more involved. GraphQL is a powerful choice, not a free win.

• A strongly-typed schema; clients query the exact fields they want
• Eliminates round-trips and over/under-fetching; schema doubles as docs
• Caching is harder than REST's URL-based caching
• Needs query-complexity limits and care around the resolver N+1 problem

When to use it

GraphQL fits well when clients have varied, complex data needs — a mobile app, a web app and third parties each wanting different slices of the same data — or when front-end teams want to iterate on data requirements without waiting for new REST endpoints. It is often unnecessary for a simple API with a fixed, small set of consumers, where REST's simplicity and easy caching win. The decision comes down to data-shape complexity and client diversity: GraphQL's flexibility pays off when many clients need many different data shapes; REST's simplicity wins when needs are straightforward and stable.

• Best when many clients need varied, complex slices of the same data
• Lets front-end teams iterate without waiting for new endpoints
• Often unnecessary for a simple API with fixed consumers
• Choose it for client diversity and complex data; REST for simple, stable needs