What does a GraphQL server do with a request's document before any resolver runs?

## The pipeline Every GraphQL request goes through the same three phases, in the same order, and each one consumes strictly more than the last. **Parse** takes the document text — the string a client sent as its operation — and produces a syntax tree of definitions: operations, their variable definitions, selection sets, arguments, fragment definitions, directives. Parsing consults *nothing else*. There is no schema involved, no request context, no data. It is a pure function from text to tree, and the only way it can fail is grammatically: an unclosed brace, a missing closing quote, a stray token, an empty document. **Validate** is the first phase that needs the schema. It walks the parsed tree against the type system and applies the specification's static rules — the rules themselves are a topic of their own; what matters here is the phase boundary. Validation still sees no runtime data and calls no resolver; given the same document and the same schema it always reaches the same verdict, which is why it can be run in continuous integration rather than on the request path. **Execute** is where the request finally becomes work. The server picks which operation in the document to run, coerces the request's variable values against their declared types, and then resolves the selection set. This is the first phase that touches your code and your data stores. ## What a syntax error means, exactly Because the phases are ordered, a syntax error is an unusually informative failure: it tells you the server never got as far as *looking at your schema*. No validation rule ran. No operation was selected. No variable was coerced. No resolver, no database call, no authorisation check. Consider a real-estate listings client that drops a closing brace: ```graphql query ListingCard { listing(id: "LST-4417") { streetAddress priceCents } ``` The server answers with something like: ```json { "errors": [ { "message": "Syntax Error: Expected Name, found <EOF>.", "locations": [{ "line": 5, "column": 1 }] } ] } ``` Three details in that response are worth knowing. First, there is **no `data` key**. The specification is explicit that when a request fails *before execution* — a syntax error, a missing operation, a validation failure — the `data` entry must not be present in the response; `data: null` is a different statement, meaning execution began and a non-null failure removed everything. Second, the error carries `locations`, a line and column pointing into the document source as the server received it, and no `path`, because a path names a position in a response that does not exist. Third, there is usually exactly one error: parsers abort at the first token they cannot make sense of rather than attempting recovery, so a syntax error is not a list of every problem in the document. A parse failure is a **request error** — the request as a whole was rejected — as opposed to a field error raised by a resolver during execution. The taxonomy of the response envelope belongs to the errors topic; the point here is that the phase that failed determines which kind you get. The HTTP status that carries such a response is governed by the GraphQL over HTTP specification and depends on the media type in play, which is a transport concern rather than a lexical one. ## Why the ordering earns its keep The practical value of knowing the pipeline is triage. The phase that rejected a request tells you where the fault lives, and the three answers point at three different teams: - **Parse failed** — the fault is in the bytes of the document the client sent. The schema is irrelevant; a rename, a deploy, a database outage cannot cause this. - **Validate failed** — the document is well-formed but disagrees with the schema. A field that does not exist, a required argument left out, a fragment spread on an impossible type. This is a contract mismatch between a client build and a schema version. - **Execution produced errors** — the document was fine and your resolvers, or something behind them, misbehaved. That is why a candidate who says "a typo in a field name is a syntax error" is marked down. A misspelled field parses perfectly — `stretAddress` is a grammatically valid name — and is rejected one phase later, by validation, with a different error shape and a completely different investigation. ## Cost, and moving phases off the request path Parsing and validating are cheap next to execution — a couple of kilobytes of document is microseconds of parsing against a request budget measured in hundreds of milliseconds — but they are not free, and they are *pure*. Parse depends only on text, validate only on text plus schema. That purity is what lets a platform move both off the hot path: documents can be checked at build time in a client's pipeline, and the specification permits a server to skip validation for a document it has already validated. How a server actually retains and reuses a checked document is a caching concern owned elsewhere; the ordering of the phases never changes. ## Interview framing The question is usually asked as "walk me through what happens when a query arrives". Name the three phases, say what each one consumes, and then show you can use the boundary: a syntax error means the client's text is broken, a validation error means the client and the schema disagree, and only after both pass does any of your code run.