GraphQL Interview Questions: Core Concepts to Advanced Patterns

Scalars are the leaves of a GraphQL query — once a field resolves to a scalar, there's nothing further to select underneath it (unlike an object type, where you must specify which of its sub-fields you want). GraphQL ships five built-in scalars (Int, Float, String, Boolean, ID) and schemas commonly define custom ones (DateTime, EmailAddress) with their own serialize/parse logic. Scalars are usable both as return types and as input argument types — they're not restricted to one side.

GraphQL resolves each field independently. When a list of N items each resolve a related child field, the default per-resolver execution issues one query per item, producing 1 + N database round-trips.

When a parent resolver returns null, GraphQL short-circuits and returns null for the entire field subtree. The Product.price resolver is never invoked, so no error occurs — the response for product is simply null.

Line 5 hashes JSON.stringify(variables) instead of the query document string. A persisted-query hash must be derived from the query text so that the same operation always yields the same hash regardless of the variables passed in. Hashing the variables means the hash changes on every call with different inputs, the server can never match it to a stored query, and the purpose of persisted queries is defeated. The correct line would be .update(query).

The spec treats the two root types differently at execution time: fields under Query (and the sibling fields of a nested selection) may be resolved in parallel since reads shouldn't interfere with each other, while top-level fields under Mutation are executed serially, one completing before the next starts, precisely because mutations have side effects and unordered writes would be unpredictable. This is a load-bearing distinction, not just naming — if you send a mutation document with three top-level mutation fields expecting them to apply in order, that ordering is actually guaranteed by the spec.

The GraphQL spec defines exactly three root operation types a schema can expose: Query for reads, Mutation for writes, and Subscription for a persistent connection streaming updates over time (typically over WebSockets or SSE). Fragment and Resolver are real, load-bearing GraphQL concepts, but neither is a root operation type — a fragment is a reusable named selection set you spread into a query, and a resolver is the server-side function that produces a field's value, not something the client selects.

True. This is the founding motivation behind GraphQL's client-specified field selection: instead of a server dictating a fixed response shape per endpoint (forcing overfetching when it returns more than needed, or underfetching when it returns less, requiring extra round trips), the client describes exactly the shape of data it wants in one query and the server assembles precisely that in a single response.

Resolvers are where a GraphQL schema meets real data — the schema is only the contract; resolvers are the implementation that fulfils it, one field at a time.

The N+1 problem arises because a parent resolver returns N items and a child field resolver fires once per item. DataLoader fixes this by not hitting the data source on each load() call — it queues the key and returns a Promise. After the current execution tick, DataLoader dispatches all queued keys together in one batch, the batch function issues a single data-source request and returns results in key order, and each individual Promise resolves with its mapped result so GraphQL continues building the response.

DataLoader's load() method never fetches immediately: it enqueues the key and returns a Promise. The actual fetch is deferred until the scheduler fires after the current tick. At dispatch the batch function receives all queued keys at once and makes one request. Results are then written to the in-memory cache so subsequent loads for the same key are served from cache, and finally each pending Promise resolves with its value.

The GraphQL spec defines three valid top-level response keys: data (the result of execution, possibly null), errors (a list of field or request errors), and extensions (an optional map of implementation-defined metadata). meta and status are not part of the GraphQL specification.

This is the canonical GraphQL N+1: 1 query for the list plus N queries for a per-item related field, and it appears anywhere a resolver naively fetches its own data instead of coordinating with its siblings. The fix isn't caching or indexing (those help latency per-query, not query count) — it's batching: collect all the author ids requested during one execution tick and issue a single WHERE id IN (...) query for all of them, then hand each resolver its own row from the batched result. DataLoader (and equivalents in other languages) is the standard pattern: it request-scopes both the batching and a de-dup cache so the same id is never fetched twice in one request.

Overfetching and underfetching are the two REST pain points GraphQL's design directly targets. A fixed REST response shape either returns more than a given screen needs (overfetching — wasted bandwidth) or forces multiple endpoint calls to assemble what one screen needs (underfetching — wasted round-trips). GraphQL's single endpoint plus client-specified field selection lets one request return exactly the shape needed, addressing both at once. PATCH is about partial writes, unrelated to underfetching on reads; and overfetching is a REST problem GraphQL was built to avoid, not something unique to GraphQL.

True. The GraphQL spec itself is transport-agnostic and doesn't mandate an HTTP status code for field errors; in practice, the overwhelming majority of servers (Apollo Server among them) return HTTP 200 for a request that executed and produced a partial response with populated errors, reserving non-200 statuses for transport-level failures like a malformed request or auth rejection before execution even starts. A client has to inspect the response body's errors array, not the status code, to know whether a GraphQL-level failure occurred.

A fragment is GraphQL's mechanism for not repeating yourself: name a selection set once against a type, then spread it (...FragmentName) into as many operations as need that exact shape. Beyond avoiding literal duplication, fragments are the basis of the 'colocate data requirements with the component that needs them' pattern used by client libraries like Apollo and Relay — each UI component declares its own fragment, and a parent query composes the fragments of everything it renders without needing to know their internal field lists.

Variables separate the shape of a request (the query) from its data (the variables), which is exactly what makes a query reusable, cacheable, and safe from injection-style string-building bugs.

This is the fixed pipeline every spec-compliant GraphQL server follows: parse the raw query text into a structured AST, validate that AST against the schema (catching typos, wrong argument types, or fields that don't exist before any resolver runs), execute by calling resolvers for each selected field — parent fields before their children, since a child resolver often needs its parent's already-resolved value — and finally serialize whatever was collected (plus any errors gathered along the way) into the response shape. Validation happening before execution is why a malformed query fails fast with a clear error instead of partially executing and returning confusing partial data.

This is the GraphQL spec's null-bubbling rule. When a field error occurs, the field's value is set to null. If the field's type is non-null, that null is invalid, so the parent field is set to null instead. This continues upward until a nullable field is found, which absorbs the null. Fields above that nullable ancestor are unaffected and retain their resolved values. The error is also recorded in the errors array with a path indicating where it originated.

Apollo's APQ protocol works in two phases. On the first request the client sends only the extensions.persistedQuery.sha256Hash field and no query field. If the server's cache does not contain a mapping for that hash, it returns a GraphQL error whose extensions.code is PERSISTED_QUERY_NOT_FOUND. The client then re-sends the request with both the hash and the full query text; the server executes and stores the mapping so subsequent requests need only the hash. The companion error PERSISTED_QUERY_NOT_SUPPORTED is used when the server opts out of APQ entirely.

Apollo's defaultDataIdFromObject returns ${object.__typename}:${object.id} (falling back to _id when id is absent). This normalization key lets the cache deduplicate an entity — say, a User with id 42 — regardless of which query or mutation returned it. When a subsequent mutation or query returns the same __typename and id, the cache merges the fields into the existing entry and any component subscribed to that fragment re-renders with the updated data. You can override the key generation by passing a custom dataIdFromObject function to the InMemoryCache constructor.

Each post in the list independently triggers this resolver, and each invocation runs its own round trip to the database — for a page of 50 posts, that's 50 extra queries beyond the one that loaded the posts themselves. GraphQL resolvers being async is normal and required for any I/O; the parameterized query on line 4 is actually the correct, injection-safe way to write it. The fix is to replace the direct per-call ctx.db.query with a batching loader (e.g. a DataLoader keyed by post.id) that collects every id requested during one execution tick and issues a single WHERE post_id = ANY($1)-style query for all of them, then hands each resolver its own slice of the batched result.

The mechanism to get right: GraphQL resolves each field's resolver independently, so per-item related fields naturally fall into N+1 unless something coordinates across sibling resolvers within one execution tick. DataLoader's trick is exactly that coordination — it defers each individual load request to the end of the current tick (via a microtask), collects everything requested, and issues one batched query, plus a request-scoped cache so repeated requests for the same id are free. Understanding why naive resolvers produce N+1 (independent execution, no shared context) is what separates a real answer from reciting 'use DataLoader'.

The Query.product resolver returns { id: "p1", basePrice: 100 } — note that discount is NOT a property of this object. The Product.discount field resolver returns 20, but that resolved value does NOT get written back onto the parent object; it only appears in the output. When Product.finalPrice runs, parent is still the raw { id: "p1", basePrice: 100 }, so parent.discount is undefined and (parent.discount || 0) evaluates to 0, giving 100 - 0 = 100. The same logic applies at every level: Review.product returns { id: "p1", basePrice: 100 } (again without discount), so finalPrice is 100 for the nested product too. The discount field itself resolves to 20 in the top-level output. This is the key resolver-chain insight: sibling field resolvers cannot see each other's resolved values — only what the parent resolver returned.

The spec's CompleteValue / HandleFieldError logic dictates that a null result for a Non-Null field invalidates the parent. Propagation continues upward through consecutive Non-Null parents until a Nullable ancestor absorbs it. If no nullable ancestor exists — meaning the root operation field itself is Non-Null — the whole data object is replaced with null. This is why Non-Null fields are sometimes called 'null propagation bombs': a single resolver failure deep in the tree can null out large portions of or the entire response.

The bug is on line 9. The createPersistedQueryLink detects PersistedQueryNotFound (and PersistedQueryNotSupported) by inspecting response.errors inside the observable's next handler — it needs the server response to arrive as a next event so it can read the extensions.code. The errorLink, sitting between the PQ link and the HTTP link in the chain ApolloLink.from([persistedQueryLink, errorLink, httpLink]), intercepts the response from the HTTP link and, on line 9, converts every GraphQL-level error (including PersistedQueryNotFound) into a thrown error via observer.error(new Error(...)). Because the response never reaches the PQ link as a next event, the PQ link's error-detection logic never fires and it never retries with the full query text. The PQ link receives the error through its error handler, which simply re-throws it to the application. The fix is to pass observer.next(response) for GraphQL errors (letting the PQ link inspect them) and only throw for unexpected transport-level errors, or to place the error-handling link before the PQ link in the chain so it does not sit between the PQ link and its forward target. Lines 14–15 correctly forward transport errors and completion; line 23 has the correct link ordering; line 20 correctly creates the PQ link with a sha256 function.