GraphQL Cheat Sheet

GraphQL is a typed query language and runtime for APIs: the server publishes a schema describing every type and field it can serve, and each client sends a query describing exactly the shape of data it wants - one round trip, no over-fetching (fields you did not ask for) and no under-fetching (chaining three REST calls to build one screen). Everything goes over a single endpoint (conventionally POST /graphql); the 'REST verbs' live in the schema instead, as three operation types. The runtime resolves a query by walking its tree and calling a resolver function per field. Interviews use GraphQL to probe API design judgment: the schema-first mindset, the N+1 trap, pagination, and whether you can articulate when NOT to use it.

Object type

The unit of the schema: type User { id: ID!, name: String!, posts: [Post!]! }. Fields have types; ! means non-null. [Post!]! reads as 'a non-null list of non-null Posts'.

Root types: Query / Mutation / Subscription

Three special object types that are the entry points. Every operation starts at one of them; everything else is reached by traversing fields.

Scalars & enums

Built-in scalars: Int, Float, String, Boolean, ID. Custom scalars (DateTime, JSON) carry their own serialization/validation. Enums constrain a field to named values.

Input types

Arguments cannot take object types - they take input types (input CreatePostInput { title: String! }). Keeps the write shapes separate from the read shapes.

Interfaces & unions

Interface = shared fields with per-type implementations (interface Node { id: ID! }). Union = 'one of these types, no shared fields' (union SearchResult = User | Post). Clients branch with inline fragments: ... on User { name }.

Resolver

A function per field: (parent, args, context, info) => value. parent is the parent field's resolved value, context carries per-request state (auth, loaders, db handles). Fields without an explicit resolver default to reading the property off parent.

Execution model

The server validates the query against the schema, then resolves the tree top-down - sibling fields in parallel, children after their parent. This per-field resolution is both GraphQL's power and the origin of N+1.

Introspection

The schema is queryable (__schema, __type) - this powers GraphiQL, codegen, and autocompletion. Standard practice: disable or restrict introspection in production on non-public APIs.

Query

Read. Side-effect-free by contract. Top-level query fields resolve in parallel. The analog of GET - and like GET, should be safe to retry.

Mutation

Write. Top-level mutation fields in one request run serially, in order - the one execution-order guarantee GraphQL makes. Convention: verb-named (createPost), takes one input object, returns the mutated entity (so the client's cache can update) plus any user-facing errors.

Subscription

Server push. The client registers a subscription (usually over WebSocket or SSE) and receives a result each time the server publishes the matching event. Use for live-updating data (chat, presence, dashboards); for occasional freshness, polling a query is simpler and cheaper.

Operation anatomy

query GetUser($id: ID!) { user(id: $id) { name } } - named operation, typed variables (never string-interpolate values into query text), field selection. Fragments (fragment UserCard on User { ... }) share selections across queries.

Ask for { posts(first: 50) { title author { name } } } with naive resolvers and you get 1 query for the posts plus 50 queries for the authors - one per Post.author resolver call. That is N+1, and it is the single most-asked GraphQL interview question. The standard fix is DataLoader (or an equivalent batching layer): a per-request cache-and-batcher. Each resolver calls loader.load(authorId) instead of hitting the database; the loader collects every id requested within the current tick of execution, issues ONE batched query (WHERE id IN (...)), and fans results back out to each caller - it also dedupes, so the same author requested twice costs one lookup. Two rules interviewers listen for: the loader must be created per request (a shared loader leaks one user's cached data into another's response, and goes stale), and the batch function must return results in the same order as the input keys. Batching solves query count, not query cost - a deeply nested query can still be expensive, which is what the security section is for.

The errors array

A response is { data, errors }. A resolver that throws adds an entry to errors with a message and a path to the failing field - and data is PARTIAL: the failed field becomes null while sibling fields still return. Clients must check both keys.

Null bubbling

If a non-null (!) field errors, null is illegal there, so the null propagates up to the nearest nullable ancestor - one failed field can blank out a whole subtree. Schema design lesson: non-null is a promise; reserve ! for fields that cannot fail independently.

extensions.code

Machine-readable error metadata by convention: { extensions: { code: "UNAUTHENTICATED" } }. Never encode error kinds in message strings clients must parse.

Errors-as-data

For expected domain outcomes (validation failure, 'name taken'), return them in the schema instead of throwing: mutation returns union CreateUserResult = User | ValidationError. Typed, client-handled, and keeps the errors array for genuinely exceptional failures. Strong senior-signal answer.

Masking internals

Resolver exceptions should be logged server-side and replaced with a generic message in the response - stack traces and SQL in the errors array are an information leak.

Depth limiting

Reject queries nested beyond N levels before executing. Kills the classic { user { friends { friends { friends ... }}}} recursion attack. Cheap to enforce from the parsed AST; a sane API rarely needs depth beyond ~10.

Query cost / complexity analysis

Assign each field a cost (list fields multiply by first/limit args), compute the query's total statically, reject over budget. Catches wide-but-shallow queries depth limits miss. Rate-limit by consumed cost, not request count.

Persisted / trusted queries

Clients may only send pre-registered query hashes, not arbitrary query text. Shrinks the attack surface to queries you shipped, and doubles as a bandwidth win. The standard hardening for first-party-client APIs.

Introspection & suggestions off in prod

Disable introspection and 'did you mean' field suggestions on non-public APIs so the schema is not free reconnaissance.

AuthZ at the field/entity layer

One endpoint means route-level middleware cannot express permissions. Enforce authorization per field or per entity in resolvers/directives - and remember every type is reachable from every query path that returns it.

Batching abuse & aliases

Aliases let one document repeat a field many times (a: login(...) b: login(...) - a brute-force amplifier). Cap aliases and batched operations per request.

• ·HTTP 200 does not mean success - check the errors array. Monitoring that alerts on 5xx only is blind to a GraphQL API that is failing every request politely.
• ·Non-null (!) is a contract, not decoration - one failed non-null leaf can null-bubble away an entire response subtree.
• ·DataLoader instances are per-request - sharing one across requests leaks data between users and serves stale reads.
• ·Mutations run serially at the top level, queries in parallel - and only the top level; nested resolution is concurrent either way.
• ·N+1 applies to any backend call, not just SQL - REST calls and microservice fan-out from resolvers need batching too (or a federation layer).
• ·One endpoint breaks endpoint-based tooling assumptions - rate limiting, caching, and access logs all need query-aware equivalents (cost budgets, persisted queries, operation names in logs).
• ·Schema evolution: prefer additive changes plus @deprecated over versioned schemas - deleting or retyping a field is a breaking change clients cannot opt out of.
• ·Variables, always - building query strings by concatenating user input reintroduces injection into a system designed to prevent it.