GraphQL formatting cannot replace schema validation

A GraphQL formatter can make selection sets and arguments readable, but a document can be syntactically correct and still be impossible or unsafe to execute against a schema. Separate formatting from parsing, validation, variable coercion, and authorization.

Parsing answers only the grammar question

The GraphQL specification defines the executable document grammar for operations and fragments. A parser can identify missing braces, malformed variable definitions, or invalid token placement without knowing the server schema.

This query is syntactically valid:

query Account($id: ID!) {
  account(id: $id) {
    id
    displayName
  }
}

It becomes meaningful only when validated against a schema that defines Query.account, its argument, and the selected fields.

GraphQL TV conference session on schema-defined rate limiting at production scale. The video complements the article's validation and resource-control checklist.

Validation requires the target schema

The specification’s validation rules cover issues such as unknown fields, impossible fragment spreads, missing required arguments, incompatible variable types, duplicate operation names, and selecting a composite field without a subselection. A generic formatter cannot make those decisions without the schema version deployed by the endpoint.

Label schema-aware results with an endpoint or schema revision. A query validated against staging can fail after a production schema change or when sent to a different service.

Variables have a separate coercion step

Formatting the operation does not validate its JSON variables. Check that required variables are present, values match GraphQL input types, enum values are known, and input objects do not contain unexpected fields. Keep variables separate from the query text so values do not need string interpolation.

Validation is not authorization

A schema-valid operation may still request data the current principal cannot access. Resolvers and the application’s authorization layer must enforce object- and field-level policy. Introspection visibility, query allowlists, depth limits, complexity budgets, pagination limits, and timeouts are deployment controls—not formatter features.

Review workflow

Parse and format the operation without changing names, values, directives, or selection order.
Resolve fragment definitions and confirm every referenced fragment exists.
Validate against the exact target schema.
Coerce variables using the schema’s input types.
Estimate depth or complexity using the server’s rules.
Exercise authorization with representative identities.
Compare the response shape with the consumer’s expectations.

Persisted queries should bind the reviewed document to a stable identifier or digest. Reformatting must not silently change the canonical text used by that protocol.