Nested resolver execution in GraphQL - Step-by-Step Execution

Concept Flow - Nested resolver execution

Client sends query

↓

Root resolver called

↓

Fetch root data

↓

For each nested field

↓

Call nested resolver

↓

Fetch nested data

↓

Return nested data

↓

Combine nested data with root

↓

Return full response to client

The query starts at the root resolver, which fetches main data, then calls nested resolvers for subfields, combining all results before sending back.

Execution Sample

GraphQL

query {
  user(id: 1) {
    id
    name
    posts {
      id
      title
    }
  }
}

Fetch user with id 1, including their posts with post id and title.

Execution Table

Step	Resolver Called	Input Arguments	Action	Output
1	user	id=1	Fetch user data from DB	{id:1, name:'Alice'}
2	posts	userId=1	Fetch posts for user 1	[{id:101, title:'Hello World'}, {id:102, title:'GraphQL Rocks'}]
3	Combine	user + posts	Attach posts to user object	{id:1, name:'Alice', posts:[{id:101, title:'Hello World'}, {id:102, title:'GraphQL Rocks'}]}
4	Return	full user object	Send response to client	Full user with posts data

💡 All nested resolvers completed, full data assembled and returned.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
userData	null	{id:1, name:'Alice'}	{id:1, name:'Alice'}	{id:1, name:'Alice', posts:[...]}	{id:1, name:'Alice', posts:[{id:101, title:'Hello World'}, {id:102, title:'GraphQL Rocks'}]}
postsData	null	null	[{id:101, title:'Hello World'}, {id:102, title:'GraphQL Rocks'}]	[{id:101, title:'Hello World'}, {id:102, title:'GraphQL Rocks'}]	[{id:101, title:'Hello World'}, {id:102, title:'GraphQL Rocks'}]

Key Moments - 2 Insights

Why does the nested 'posts' resolver run after the 'user' resolver?

Because the 'posts' resolver needs the user id from the 'user' resolver's result to fetch posts. See execution_table rows 1 and 2.

How is the final response assembled with nested data?

After fetching nested posts, the data is attached to the user object before returning. See execution_table row 3.

Visual Quiz - 3 Questions

Look at the execution_table, what is the output of the 'user' resolver at step 1?

A [{id:101, title:'Hello World'}]

B {id:1, name:'Alice'}

C Full user with posts data

D null

💡 Hint

Check the 'Output' column in row 1 of execution_table.

At which step does the nested 'posts' resolver fetch data?

A Step 3

B Step 1

C Step 2

D Step 4

💡 Hint

Look at the 'Resolver Called' and 'Action' columns in execution_table.

If the 'posts' resolver returned an empty list, how would 'userData' change after step 3?

A It would have posts as an empty list

B It would have no posts field

C It would be null

D It would contain posts with null values

💡 Hint

See variable_tracker for how postsData attaches to userData.

Concept Snapshot

GraphQL nested resolvers run in order: root resolver fetches main data,
then nested resolvers fetch subfield data using parent info.
Results combine before returning full response.
Each resolver gets arguments from parent data.
This allows complex data fetching in one query.

Full Transcript

In GraphQL, when a client sends a query with nested fields, the server starts by calling the root resolver. This resolver fetches the main data, such as a user by id. Then, for each nested field like posts, the server calls the nested resolver, passing necessary arguments like user id. The nested resolver fetches its data, for example, posts belonging to the user. After all nested resolvers finish, their results are combined with the root data to form the full response. This process ensures each part of the query is resolved step-by-step, building the complete data structure to send back to the client.

Practice

1. What is the main purpose of nested resolver execution in GraphQL?

easy

A. To convert GraphQL queries into SQL statements

B. To execute multiple queries in parallel without relation

C. To cache all data before sending a response

D. To fetch related data step-by-step using parent data

Solution

1. Step 1: Understand nested resolver role

   Nested resolvers use parent data to fetch related child data step-by-step.

2. Step 2: Compare other options

   Options B, C, and D describe unrelated or incorrect behaviors for nested resolvers.

3. Final Answer:

   To fetch related data step-by-step using parent data -> Option D

4. Quick Check:

   Nested resolver execution = step-by-step data fetch [OK]

Hint: Nested resolvers use parent info to get related data [OK]

Common Mistakes:

• Thinking nested resolvers run unrelated queries
• Confusing caching with resolver execution
• Assuming nested resolvers convert queries to SQL

2. Which of the following is the correct syntax for a nested resolver function in GraphQL?

easy

A. resolver(parent.id, fetchChildData)

B. fetchChildData(parent.id) => parent

C. parent => fetchChildData(parent.id)

D. child => parent.fetchData()

Solution

1. Step 1: Identify correct resolver signature

   Nested resolvers receive the parent object and use its fields to fetch related data, e.g., parent => fetchChildData(parent.id).

2. Step 2: Eliminate incorrect syntax

   Options B, C, and D do not follow the standard resolver function pattern.

3. Final Answer:

   parent => fetchChildData(parent.id) -> Option C

4. Quick Check:

   Nested resolver syntax = parent => fetchChildData(parent.id) [OK]

Hint: Nested resolver gets parent, then fetches child data [OK]

Common Mistakes:

• Reversing function parameters
• Using child as input instead of parent
• Incorrect arrow function placement

3. Given this GraphQL resolver snippet:

const resolvers = {
  User: {
    posts: (parent) => {
      return posts.filter(post => post.userId === parent.id);
    }
  }
};

What will User.posts return when called with parent = { id: 2 } if posts = [{id:1,userId:2},{id:2,userId:3},{id:3,userId:2}]?

medium

A. Error: posts is undefined

B. [{id:1,userId:2},{id:3,userId:2}]

C. []

D. [{id:2,userId:3}]

Solution

1. Step 1: Filter posts by parent.id

   The resolver filters posts where post.userId equals parent.id (2), so posts with userId 2 are selected.

2. Step 2: Identify matching posts

   Posts with id 1 and 3 have userId 2, so they are returned.

3. Final Answer:

   [{id:1,userId:2},{id:3,userId:2}] -> Option B

4. Quick Check:

   Filter posts by userId=2 = matching posts [OK]

Hint: Filter posts where userId matches parent.id [OK]

Common Mistakes:

• Returning posts with wrong userId
• Confusing parent.id with post.id
• Assuming empty result without checking data

4. Consider this nested resolver code:

const resolvers = {
  Author: {
    books: (parent) => {
      return books.filter(book => book.authorId = parent.id);
    }
  }
};

What is the error in this resolver?

medium

A. Using assignment '=' instead of comparison '===' in filter

B. Missing return statement in resolver

C. Incorrect resolver name 'books' instead of 'bookList'

D. Parent argument is not passed to resolver

Solution

1. Step 1: Identify filter condition mistake

   The filter uses '=' which assigns value instead of '===' which compares values.

2. Step 2: Understand impact of '=' in filter

   Using '=' causes all books to be included or unexpected behavior, not filtering correctly.

3. Final Answer:

   Using assignment '=' instead of comparison '===' in filter -> Option A

4. Quick Check:

   Filter condition must use '===' not '=' [OK]

Hint: Use '===' for comparison inside filter functions [OK]

Common Mistakes:

• Confusing '=' with '===' in conditions
• Forgetting to return filtered array
• Assuming resolver name must match data variable

5. You have a GraphQL schema with Author and nested books resolver. How would you optimize nested resolver execution to avoid fetching all books for each author individually?

hard

A. Batch book fetching using DataLoader to group requests by authorId

B. Fetch all books once and filter in each resolver call

C. Remove nested resolver and fetch books separately in client

D. Use multiple nested resolvers for each book field

Solution

1. Step 1: Understand nested resolver inefficiency

   Fetching books individually per author causes many database calls, slowing performance.

2. Step 2: Apply batching with DataLoader

   DataLoader batches requests by authorId, fetching all needed books in one query efficiently.

3. Final Answer:

   Batch book fetching using DataLoader to group requests by authorId -> Option A

4. Quick Check:

   Batching nested fetches = DataLoader usage [OK]

Hint: Use DataLoader to batch nested resolver database calls [OK]

Common Mistakes:

• Fetching all books every time wastes memory
• Removing nested resolver loses data relation
• Using multiple nested resolvers increases calls