Operations, fragments, variables, persisted queries, and query depth — how clients interact with GraphQL efficiently.
Key vocabulary
Operation — a named query, mutation, or subscription in GraphQL.
Fragment — a reusable selection set that can be included in multiple operations.
Variables — dynamic values passed into an operation, separated from the query string.
Persisted queries — pre-registered queries identified by a hash, sent by ID instead of full text.
Query depth limiting — rejecting queries that nest too many levels deep.
0 / 5 completed
1 / 5
A fragment in GraphQL is used to:
Fragment = a reusable selection set. Example: fragment UserFields on User { id name email } can be included with ...UserFields. Benefits: DRY, consistent data shapes, works well with component-based UIs.
2 / 5
Variables in GraphQL operations:
Variables = parameterised queries. Instead of embedding values in the query string, declare a variable and pass it separately. Benefits: (1) prevents injection attacks, (2) enables parsing and caching to be separated from value substitution.
3 / 5
Persisted queries improve performance by:
Persisted queries: the client registers queries at build time; at runtime sends only the hash. Benefits: smaller payloads, security (only pre-approved queries execute), and automatic allow-listing in production.
4 / 5
Query complexity analysis assigns costs to fields to:
Query complexity analysis: scalars are cheap, lists are expensive, nested types add up. If the total exceeds the configured maximum, the query is rejected. Prevents malicious or naive clients from sending resource-exhausting queries.
5 / 5
Query depth limiting prevents:
Query depth limiting rejects queries exceeding a maximum nesting depth. Without a depth limit, deeply nested queries trigger exponential resolver calls — effectively a DoS attack on the GraphQL server.