Query depth and complexity in GraphQL - Step-by-Step Execution

Concept Flow - Query depth and complexity

Start Query

↓

Parse Query

↓

Calculate Depth

↓

Calculate Complexity

↓

Compare with Limits

↓

Execute

↓

Return Data

The query is parsed, its depth and complexity are calculated, then checked against limits to decide if it runs or is rejected.

Execution Sample

GraphQL

query {
  user {
    posts {
      comments {
        text
      }
    }
  }
}

This query fetches users, their posts, and comments text, showing nested depth and complexity.

Execution Table

Step	Action	Current Depth	Complexity Score	Decision
1	Start parsing query	0	0	Continue
2	Enter 'user' field	1	1	Continue
3	Enter 'posts' field inside 'user'	2	3	Continue
4	Enter 'comments' field inside 'posts'	3	6	Continue
5	Read 'text' field inside 'comments'	4	7	Continue
6	Calculate total depth = 4	4	7	Check limits
7	Calculate total complexity = 7	4	7	Check limits
8	Compare depth (4) with max allowed (5)	4	7	OK
9	Compare complexity (7) with max allowed (10)	4	7	OK
10	Execute query and return data	4	7	Done

💡 Query depth and complexity are within allowed limits, so query executes successfully.

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 5	Final
Current Depth	0	1	2	3	4	4
Complexity Score	0	1	3	6	7	7

Key Moments - 2 Insights

Why does the complexity score increase more than the depth at some steps?

Because complexity counts the number of fields and nested calls, not just depth. For example, at step 3, depth is 2 but complexity is 3 due to multiple fields inside.

What happens if the query depth exceeds the allowed maximum?

The query is rejected before execution to protect the server, as shown in the decision step after calculating depth (step 8).

Visual Quiz - 3 Questions

Look at the execution table, what is the complexity score after entering the 'comments' field (step 4)?

A 6

B 4

C 3

D 7

💡 Hint

Check the 'Complexity Score' column at step 4 in the execution table.

At which step does the query depth reach its maximum value?

A Step 6

B Step 3

C Step 5

D Step 9

💡 Hint

Look at the 'Current Depth' column and find the highest number.

If the max allowed complexity was 5 instead of 10, what would happen at step 9?

A Query would execute normally

B Query would be rejected due to high complexity

C Depth would be recalculated

D Complexity would decrease

💡 Hint

Compare the complexity score at step 9 with the new max allowed complexity.

Concept Snapshot

Query depth and complexity measure how nested and costly a GraphQL query is.
Depth counts nested levels; complexity counts fields and nested calls.
Servers set max limits to avoid slow or harmful queries.
Queries exceeding limits are rejected before running.
Calculations happen after parsing, before execution.

Full Transcript

This visual trace shows how a GraphQL query is processed to check its depth and complexity. The query is parsed, then each nested field increases depth and complexity scores. The depth is the number of nested levels, while complexity counts the total fields and nested calls. After calculating these, the server compares them to allowed maximums. If the query is within limits, it runs and returns data. If not, it is rejected to protect server performance. This helps keep queries efficient and safe.

Practice

1. What does query depth in GraphQL control?

easy

A. The maximum number of nested levels in a query

B. The total number of fields requested in a query

C. The size of the response data in bytes

D. The number of queries a client can send per minute

Solution

1. Step 1: Understand query depth meaning

   Query depth limits how many nested levels a GraphQL query can have to avoid very deep queries.

2. Step 2: Compare with other options

   Options A, C, and D describe different concepts like total fields, response size, or rate limiting, not depth.

3. Final Answer:

   The maximum number of nested levels in a query -> Option A

4. Quick Check:

   Query depth = nested levels limit [OK]

Hint: Depth means nested levels, not total fields or size [OK]

Common Mistakes:

• Confusing depth with total number of fields
• Thinking depth limits response size
• Mixing depth with request rate limits

2. Which of the following is a correct way to limit query depth in a GraphQL server?

easy

A. Disable introspection queries

B. Set a maximum response size in bytes in the schema definition

C. Limit the number of clients connected to the server

D. Use a middleware that counts nested fields and rejects queries exceeding a limit

Solution

1. Step 1: Identify how to limit query depth

   Limiting query depth is done by counting nested fields during query parsing and rejecting if too deep.

2. Step 2: Evaluate other options

   Options A, B, and C do not directly limit query depth; they affect response size, connections, or introspection.

3. Final Answer:

   Use a middleware that counts nested fields and rejects queries exceeding a limit -> Option D

4. Quick Check:

   Middleware counts depth to limit queries [OK]

Hint: Count nested fields in middleware to limit depth [OK]

Common Mistakes:

• Confusing depth limit with response size limit
• Thinking client count limits query depth
• Believing disabling introspection limits depth

3. Given this GraphQL query:

{ user { posts { comments { text } } } }

If the server limits query depth to 2, what will happen?

medium

A. The query will fail because depth is 4

B. The query will succeed and return all nested data

C. The query will return only user and posts fields

D. The query will return only user field

Solution

1. Step 1: Calculate query depth

   The query has nesting: user (level 1) -> posts (level 2) -> comments (level 3) -> text (level 4). Depth is 4.

2. Step 2: Compare with server limit

   The server limits depth to 2, but query depth is 4, so it will be rejected.

3. Final Answer:

   The query will fail because depth is 4 -> Option A

4. Quick Check:

   Query depth 4 > limit 2, so fail [OK]

Hint: Count nested braces to find depth, compare to limit [OK]

Common Mistakes:

• Counting fields instead of nesting levels
• Assuming partial data returns on depth limit
• Ignoring that depth includes all nested levels

4. You wrote a GraphQL query that exceeds the server's complexity limit and gets rejected. What is a good way to fix it?

medium

A. Add more clients to distribute the load

B. Increase the server's memory to handle complex queries

C. Reduce the number of fields requested or simplify nested queries

D. Disable query complexity checks in the server

Solution

1. Step 1: Understand query complexity

   Query complexity measures how much work the server does; reducing fields or nesting lowers complexity.

2. Step 2: Evaluate fixes

   Increasing memory or clients doesn't reduce complexity; disabling checks risks server overload.

3. Final Answer:

   Reduce the number of fields requested or simplify nested queries -> Option C

4. Quick Check:

   Lower fields/nesting to reduce complexity [OK]

Hint: Simplify query fields and nesting to lower complexity [OK]

Common Mistakes:

• Thinking hardware upgrades fix complexity limits
• Ignoring complexity and disabling checks
• Confusing client count with query complexity

5. You want to protect your GraphQL server from expensive queries. Which combined approach best balances performance and flexibility?

hard

A. Disable all limits and rely on server scaling

B. Set a query depth limit, enforce query complexity cost, and cache frequent query results

C. Only limit query depth and ignore complexity cost

D. Allow unlimited queries but limit response size

Solution

1. Step 1: Understand protection methods

   Query depth limits nesting; complexity cost limits work done; caching speeds repeated queries.

2. Step 2: Evaluate combined approach

   Using all three balances server load and user flexibility well; other options are incomplete or risky.

3. Final Answer:

   Set a query depth limit, enforce query complexity cost, and cache frequent query results -> Option B

4. Quick Check:

   Combine depth, complexity, and caching for best protection [OK]

Hint: Use depth + complexity limits plus caching for best results [OK]

Common Mistakes:

• Relying on only one limit type
• Disabling limits and trusting scaling
• Limiting response size instead of query cost