What is GraphQL in one sentence?

GraphQL is a query language for APIs that exposes one typed schema and lets the client request exactly the fields it needs in a single request, instead of hitting many fixed endpoints.

Is GraphQL better than REST?

Neither is universally better. GraphQL shines when clients have varied data needs and you want to avoid over- and under-fetching. REST is simpler to cache and operate. Many systems use both.

Facebook (now Meta) built it internally in 2012 to power its mobile apps and open-sourced it in 2015. It is now governed by the GraphQL Foundation under the Linux Foundation.

What is a GraphQL resolver?

A resolver is a function that returns the data for one field in the schema. The GraphQL engine walks the query, calls each resolver, and assembles the response in the shape the client asked for.

Is GraphQL secure by default?

No. Because clients craft their own queries, a naive GraphQL API is exposed to deeply nested queries, expensive joins, and introspection leaks. It needs depth limiting, cost analysis, and authorization on every field.

Glossary · APIs

What is GraphQL?

GraphQL is a query language and runtime for APIs that exposes a single, strongly typed schema describing everything a client can read or change, and lets each client ask for exactly the fields it needs — no more, no less — in one round trip, instead of stitching together responses from a dozen fixed endpoints.

Where it came from

Facebook built GraphQL internally in 2012 because its mobile apps were drowning in chatty REST calls — a single news-feed screen needed data from many endpoints, and slow networks made the round trips painful. The team flipped the model: let the client send one query describing the exact tree of data it wants, and have the server return precisely that shape. They open-sourced it in 2015, and it is now stewarded by the GraphQL Foundation.

The schema is the contract

At the center of every GraphQL API is a typed schema: object types, fields, queries, mutations, and subscriptions. The schema is both documentation and a machine-readable contract — tooling can autocomplete queries, validate them before they ever hit the server, and generate fully typed client code. Compared with a REST API whose shape often lives only in human-written docs, the GraphQL schema is enforced by the runtime itself.

Over-fetching and under-fetching

The classic problem GraphQL solves is over- and under-fetching. A REST endpoint returns a fixed payload, so a mobile screen that needs three fields might download fifty, while a different screen has to call three endpoints to assemble what it needs. With GraphQL the client names the fields, the server returns exactly those, and one request replaces several. That is a real win on slow or metered connections — and a major reason GraphQL took off on mobile first.

Resolvers and the N+1 trap

Each field in the schema is backed by a resolver — a function that knows how to fetch that piece of data. The engine walks the query and calls resolvers as it goes. The danger is the N+1 problem: a list of 100 authors that each resolve their posts can fire 101 database queries. The standard fix is a batching layer (DataLoader-style) that collapses those calls, often paired with a caching layer or a load balancer in front of replicated read databases.

The tradeoffs people forget

GraphQL is not free. Because every request is a POST with a different body, the simple HTTP caching that makes REST cheap to operate no longer applies out of the box. Clients can craft arbitrarily deep, expensive queries, so you need depth limits, query-cost analysis, and persisted queries to stay safe. And authorization gets harder — you have to enforce permissions at the field level, not just per endpoint. None of this is a dealbreaker, but pretending GraphQL is strictly simpler than REST is how teams get surprised in production.

At QUANT LAB

We reach for GraphQL when a product has many client surfaces — web, iOS, Android, internal tools — with genuinely different data needs, because one typed schema beats maintaining a sprawl of bespoke endpoints. Our API development work pairs the schema with batching, query-cost limits, and field-level authorization from day one. When a system is simpler — a handful of resource types, heavy read caching — we will often recommend a REST API instead. The honest comparison lives in our REST vs GraphQL write-up.

Long-form deep-dives that use this term

All posts

Related terms

Designing or untangling a GraphQL API?

We design typed schemas, fix N+1 query storms, and lock down field-level authorization. Book a 30-minute call.

API development