GraphQL
Queries, mutations, schemas, and comparison with REST
What is GraphQL?
A query language that puts clients in control of their data
GraphQL is a query language for APIs that lets clients request exactly the data they need. Unlike REST, where each endpoint returns a fixed data structure, GraphQL exposes a single endpoint and lets the client describe the shape of the response.
All GraphQL requests go to a single endpoint (e.g., POST /graphql).
The server has a schema defining available types and operations,
and resolvers that know how to fetch data for each field.
Queries, Mutations & Subscriptions
The three operation types in GraphQL
GraphQL Operations
Click each operation to see the query and response
Schema & Type System
The strongly-typed contract between client and server
GraphQL Type Definitions
Click each type to see its SDL definition
Built-in Scalar Types
Signed 32-bit integer
64-bit floating point
UTF-8 text
true or false
Unique identifier
Type Modifiers
String! Non-nullable (required)[String] List (nullable items)[String!]! Non-null list of non-null itemsString Nullable (optional)How Resolvers Work
The execution engine behind every GraphQL query
Query Execution Flow
Watch how a query is parsed, validated, and resolved step by step
Client sends a GraphQL query specifying exactly which fields it needs
query {
user(id: "1") {
name
posts { title }
}
}Resolver Function Signature
fieldName(parent, args, context, info)
parent → result from parent resolver
args → arguments passed to the field
context → shared data (auth, DB connections)
info → query AST and execution infoREST vs GraphQL
Understanding when to use each approach
Fetching a user's profile with their posts and followers requires 3 separate requests:
/api/users/1 → returns all user fields/api/users/1/posts → returns all post fields/api/users/1/followers → returns all follower fields3 round trips, likely returns more data than needed (over-fetching)
Multiple endpoints, each returns fixed data structure. May require multiple requests for related data.
Single endpoint, client specifies exact fields needed. Fetches related data in one request.
Returns all fields even if client only needs a few. Wastes bandwidth.
Client requests only the fields it needs. No wasted data.
May need to call multiple endpoints to get all related data (N+1 requests).
Nested queries fetch all related data in a single request.
Simple HTTP caching with ETags, Cache-Control. Each URL is a cacheable resource.
Complex - POST requests are not cached by default. Requires client-side caching (Apollo, Relay).
Standard HTTP status codes (404, 500, etc). Well-understood conventions.
Always returns 200 OK. Errors are in response body. Partial data with errors is possible.
Requires explicit versioning (v1, v2) for breaking changes.
Deprecate fields instead of versioning. Clients only use the fields they need.
Natively supports multipart/form-data. Simple and well-supported.
Not built-in. Requires multipart spec extension or separate REST endpoint.
Uses standard HTTP methods and URLs. Easy to learn and debug with curl/browser.
New query language, schema definition, resolvers. Steeper learning curve.
When to Choose What?
- • REST - Simple CRUD apps, public APIs, strong caching needs, file handling
- • GraphQL - Complex data relationships, mobile apps (bandwidth), multiple client types, rapid iteration
- • Both - Many companies use REST for simple services and GraphQL as a gateway layer
Performance & Security
Common pitfalls and production-ready patterns
Key Terms to Remember
Master these terms for technical interviews