What Is GraphQL?
GraphQL is a query language for APIs paired with a server-side runtime that executes those queries against a type system you define for your data. Unlike a specific database or storage technology, GraphQL is agnostic to how data is stored — it sits between clients and your existing services, letting a client ask for exactly the fields it needs in a single request. Facebook created GraphQL in 2012 to handle the demands of its native mobile apps, then open-sourced the specification in 2015, and it is now maintained by the GraphQL Foundation under the Linux Foundation.
Cricket analogy: Just as a scorecard app lets a fan request only strike rate and boundary count for a single batter instead of downloading the full match commentary, GraphQL lets a client ask for exactly those fields from the server.
The Problem GraphQL Solves
Traditional REST APIs expose fixed endpoints that return a predetermined shape of data, which forces two common inefficiencies: over-fetching, where a client receives far more fields than it needs, and under-fetching, where a single screen requires chaining together several endpoint calls to assemble the full picture. A mobile news feed, for instance, might need an article's title, author name, and thumbnail, but a REST /articles endpoint often returns the full body, tags, comments, and related-article IDs as well, wasting bandwidth on constrained mobile networks. GraphQL addresses both problems by letting the client describe the exact shape of the response it wants in the query itself, and the server resolves precisely that shape in one round trip.
Cricket analogy: Ordering a REST-style 'full over summary' when you only wanted the final ball's outcome is over-fetching, like a highlights app sending you all six deliveries when you asked about Bumrah's yorker at the death.
Core Building Blocks: Schema, Query, Resolver
A GraphQL API is built around three core pieces: a schema that declares every type and field available and acts as a contract between client and server, a single HTTP endpoint (conventionally /graphql) that accepts all queries and mutations regardless of what data they touch, and resolver functions attached to each field that know how to fetch that field's value, whether from a SQL database, a REST service, or a cache. When a query arrives, the GraphQL execution engine walks the query's selection set and invokes the matching resolver for each requested field, assembling the results into a JSON response that mirrors the shape of the query.
Cricket analogy: A stadium's single media-accreditation desk (the endpoint) routes every journalist's request — pitch report, player interviews, ticketing — to the specific department (resolver) that actually holds that information.
query GetArticle {
article(id: "42") {
title
thumbnailUrl
author {
name
}
}
}
# Response:
# {
# "data": {
# "article": {
# "title": "Understanding GraphQL Resolvers",
# "thumbnailUrl": "https://cdn.example.com/42.jpg",
# "author": { "name": "Priya Raman" }
# }
# }
# }GraphQL is a specification, not a database or a specific server implementation — it can be implemented in any language (JavaScript, Python, Go, Java, Ruby) and can sit in front of SQL databases, REST APIs, or even other GraphQL services.
When to Reach for GraphQL
GraphQL tends to pay off most clearly in three situations: mobile applications on constrained networks that benefit from precisely-sized responses, products that aggregate data from several backend services or microservices behind one unified graph, and frontends that iterate quickly and need to add or change displayed fields without waiting on new backend endpoints. Companies like GitHub, Shopify, and Netflix adopted GraphQL specifically to give frontend teams autonomy to shape their own data requirements without constant backend coordination, since a new UI field is usually just a new field selection in an existing query rather than a new endpoint deployment.
Cricket analogy: A broadcaster covering matches in three countries with patchy stadium wifi benefits from GraphQL the way a commentary team benefits from a compressed, essentials-only data feed instead of full HD replays over a weak signal.
GraphQL is not automatically a strict upgrade over REST: it introduces its own challenges such as the N+1 query problem when resolvers fetch related data naively, harder HTTP-level caching since most requests are POSTs to one endpoint, and the need for query complexity limits to prevent clients from requesting expensive, deeply nested data.
- GraphQL is a query language and runtime for APIs, created by Facebook in 2012 and open-sourced in 2015.
- It solves over-fetching and under-fetching by letting clients specify exactly the fields they want.
- A GraphQL API has one endpoint, a schema defining available types/fields, and resolvers that fetch each field's data.
- Queries are resolved in a single round trip, even when data spans multiple backend services.
- GraphQL is a specification, not a database — it can front SQL, NoSQL, REST, or other GraphQL services.
- It shines for mobile clients on constrained networks and for teams aggregating multiple microservices.
- It trades REST's simplicity for new concerns: caching, the N+1 problem, and query complexity limits.
Practice what you learned
1. Who originally created GraphQL and when was it open-sourced?
2. What problem does GraphQL primarily solve compared to typical REST APIs?
3. How many HTTP endpoints does a typical GraphQL API expose?
4. What is a resolver in GraphQL?
5. Which of these is a genuine trade-off GraphQL introduces?
Was this page helpful?
You May Also Like
GraphQL vs REST
A practical comparison of GraphQL and REST across data fetching, versioning, and caching, and when to choose each.
The GraphQL Schema
How GraphQL's Schema Definition Language describes types, fields, and operations as the contract between client and server.
Setting Up a GraphQL Server
A hands-on walkthrough of standing up a GraphQL server with Apollo Server, from schema and resolvers to running your first query.
Related Reading
Related Study Notes in Web Development
Browse all study notesWebSockets Study Notes
Web Development · 30 topics
Web DevelopmentWebAssembly Study Notes
WebAssembly · 30 topics
Web DevelopmentgRPC Study Notes
Protocol Buffers · 30 topics
Web DevelopmentSpring Boot Study Notes
Java · 30 topics
Web DevelopmentFlask Study Notes
Python · 30 topics
Web DevelopmentDjango Study Notes
Python · 30 topics