A GraphQL request is not executed as an unexamined string. A server parses the document into tokens and an abstract syntax tree (AST), validates it against a schema, and then executes the selected operation. The GraphQL Specification defines the language and execution semantics; the separate GraphQL over HTTP working draft describes one transport.

An AST represents document structure

Consider query { user(id: "7") { name posts { title } } }. Parsing turns the field selections, argument, and nesting into structured nodes. Validation can then check that user exists in the schema, that its argument has an accepted type, and that object fields select the required subfields. A document that parses is not necessarily valid or executable. An AST is also not automatically a database query or an optimized execution plan; resolver invocation and planning details depend on the server implementation.

Validation precedes resolver execution

After selecting an operation and coercing its variables, the server resolves the requested fields and shapes the result. The GraphQL spec allows parallelization of a query’s top-level selection set. The top-level selection set of a mutation should instead execute serially so its side effects have a defined order. This rule does not serialize unrelated requests from different clients.

For example, fetching a user and their posts may lead to repeated backend lookups for each post’s author. A DataLoader batch function can collect keys requested during one execution turn and fetch them together. Its result array must align with the original key order. Batching is an application data-access technique, not a mandatory GraphQL execution feature.

GraphQL is not restricted to POST

The GraphQL language specification does not mandate HTTP as a transport. The current GraphQL over HTTP working draft requires server support for POST and permits GET as another method. GET parameters are encoded in the URL query, but GET must not execute a mutation. URL-length limits and the possibility that variables appear in URLs or logs also matter. Check the endpoint’s documented transport behavior instead of assuming every server accepts the same methods.

Types and introspection do not grant authorization

Schema types describe data shapes and input constraints; they do not automatically decide whether a user may read a particular record or field. Authorization must be enforced in resolvers or the service layer using the authenticated principal and the target resource. Apollo GraphOS Router’s authorization directives are an example from that product, not universal GraphQL language directives.

Introspection is a standard way to inspect a schema. Some production deployments disable it, but the GraphQL specification does not require every server to do so. The GraphQL learning guide places that choice within a broader strategy that may include authentication, authorization, operation safelisting, depth or breadth limits, and cost controls. Introspection policy alone is not a complete security assessment.

Bound execution cost and cache scope

Deep selections, aliases, or repeated nested relations can expand resolver work. Measure the actual schema and choose appropriate depth, alias, complexity, and timeout controls. If a DataLoader memoizes user-specific data, create it per request and place it in that request’s context; the project README warns against sharing a loader across users who can see different data. This is guidance for DataLoader, not an automatic safety property of GraphQL itself.

Sources