Depth limiting in GraphQL - Step-by-Step Execution

Concept Flow - Depth limiting

Client sends GraphQL query

↓

Parse query into AST

↓

Calculate depth of query

↓

Depth <= limit

↓

Execute query

↓

Return data

The server checks the query depth before running it. If the depth is too big, it rejects the query to keep the server safe.

Execution Sample

GraphQL

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

This query asks for user posts and their comments text, which has a depth of 4.

Execution Table

Step	Action	Current Depth	Max Depth Found	Decision
1	Start parsing root field 'user'	1	1	Continue
2	Parse 'posts' inside 'user'	2	2	Continue
3	Parse 'comments' inside 'posts'	3	3	Continue
4	Parse 'text' inside 'comments'	4	4	Continue
5	End of query fields	4	4	Check depth limit
6	Compare max depth 4 with limit 3	4	4	Reject query - depth too high

💡 Query rejected because max depth 4 exceeds limit 3

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
Current Depth	0	1	2	3	4	4
Max Depth Found	0	1	2	3	4	4
Decision	None	Continue	Continue	Continue	Continue	Reject

Key Moments - 3 Insights

Why does the depth count increase when we go inside nested fields?

Each nested field adds one level to the depth. For example, 'user' is depth 1, 'posts' inside 'user' is depth 2, and so on, as shown in execution_table rows 1 to 4.

What happens if the query depth equals the limit?

If the depth is equal to or less than the limit, the query is allowed. In this example, the query depth 4 is greater than limit 3, so it is rejected (see execution_table row 6).

Why reject queries with too much depth?

Deep queries can overload the server and slow down responses. Depth limiting protects the server by rejecting queries that are too complex, as shown in the final decision in execution_table.

Visual Quiz - 3 Questions

Look at the execution_table, what is the max depth found after parsing 'comments'?

A 2

B 4

C 3

D 1

💡 Hint

Check the 'Max Depth Found' column at Step 3 in the execution_table.

At which step does the server decide to reject the query?

A Step 4

B Step 6

C Step 5

D Step 3

💡 Hint

Look at the 'Decision' column in the execution_table where it says 'Reject query - depth too high'.

If the depth limit was increased to 5, what would be the final decision?

A Execute query

B Reject query

C Error in parsing

D Partial execution

💡 Hint

Compare the max depth 4 with the new limit 5 in the execution_table logic.

Concept Snapshot

Depth limiting in GraphQL:
- Measures how deep a query's nested fields go
- Server calculates max depth before execution
- If depth > limit, query is rejected
- Protects server from expensive queries
- Example: depth 4 query rejected if limit is 3

Full Transcript

Depth limiting in GraphQL means checking how many nested levels a query has before running it. The server parses the query and counts the depth step by step. If the depth is more than the allowed limit, the server rejects the query to keep the system safe and fast. For example, a query with user, posts, comments, and text fields has depth 4. If the limit is 3, the server will reject it. This prevents very complex queries from slowing down or crashing the server.