Parent (root) argument in GraphQL - Step-by-Step Execution

Concept Flow - Parent (root) argument

GraphQL Query Received

↓

Resolver Called

↓

Parent (root) Argument Passed

↓

Resolver Uses Parent to Access Data

↓

Return Data to Client

When a GraphQL query runs, each resolver gets a 'parent' argument that holds the result from the previous resolver, letting it access related data step-by-step.

Execution Sample

GraphQL

type Query {
  user(id: ID!): User
}

const resolver = {
  Query: {
    user: (parent, args) => {
      return getUserById(args.id);
    }
  }
};

This resolver gets called with a parent (root) argument and uses args to fetch a user by ID.

Execution Table

Step	Parent Argument	Args	Action	Result
1	{}	{id: "1"}	Call Query.user resolver	Calls getUserById("1")
2	{}	{id: "1"}	getUserById returns user object	{"id": "1", "name": "Alice"}
3	{"id": "1", "name": "Alice"}	{}	Pass user as parent to nested resolvers	User object available for child resolvers
4	User object	{}	Child resolver accesses parent to get user data	"Alice"
5	User object	{}	Return final data to client	{"user": {"id": "1", "name": "Alice"}}

💡 All resolvers finished, data returned to client

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
parent	{}	{}	{}	{"id": "1", "name": "Alice"}	{"id": "1", "name": "Alice"}
args	{}	{id: "1"}	{id: "1"}	{}	{}
result	undefined	undefined	{"id": "1", "name": "Alice"}	User object	{"user": {"id": "1", "name": "Alice"}}

Key Moments - 2 Insights

Why is the parent argument empty at the root resolver?

At the root level, the parent argument is an empty object because there is no previous resolver to pass data from, as shown in execution_table step 1.

How does the parent argument help nested resolvers?

Nested resolvers receive the parent argument containing data returned by their parent resolver, allowing them to access related fields, as seen in step 3 and 4.

Visual Quiz - 3 Questions

Look at the execution_table, what is the parent argument value at step 3?

A {"id": "1", "name": "Alice"}

B {}

C null

D {"id": "2", "name": "Bob"}

💡 Hint

Check the 'Parent Argument' column at step 3 in the execution_table.

At which step does the resolver get the user ID from args?

A Step 3

B Step 1

C Step 2

D Step 4

💡 Hint

Look at the 'Args' and 'Action' columns in execution_table step 1.

If the parent argument was not passed to child resolvers, what would happen?

A Child resolvers would get default data automatically

B The query would fail immediately

C Child resolvers would have no access to parent data

D Parent argument is irrelevant for child resolvers

💡 Hint

Refer to key_moments about how nested resolvers use the parent argument.

Concept Snapshot

GraphQL resolvers receive a 'parent' argument holding data from the previous resolver.
At the root query, parent is empty ({}).
Child resolvers use parent to access related data.
This chaining allows nested data fetching step-by-step.
Always check parent to understand resolver context.

Full Transcript

When a GraphQL query runs, each resolver function is called with a 'parent' argument. This argument contains the result returned by the previous resolver in the chain. At the root query level, the parent argument is an empty object because there is no previous resolver. The resolver uses the arguments passed in the query to fetch data, for example, fetching a user by ID. Once the user data is returned, it becomes the parent argument for any nested resolvers. These nested resolvers can then access the parent data to resolve deeper fields. This flow allows GraphQL to fetch nested data step-by-step, passing context through the parent argument. Understanding the parent argument helps you see how data flows through resolvers and how nested queries get their data.

Practice

1. What does the parent argument represent in a GraphQL resolver function?

easy

A. It is the root query object that starts the GraphQL execution.

B. It is the context object shared across all resolvers.

C. It contains the arguments passed to the current query.

D. It holds the result of the previous resolver in the resolver chain.

Solution

1. Step 1: Understand resolver chaining

   Resolvers can be nested, so the parent argument holds the output of the previous resolver in the chain.

2. Step 2: Differentiate from other arguments

   The context is shared globally, args are query inputs, and root is the initial query object, not the parent.

3. Final Answer:

   It holds the result of the previous resolver in the resolver chain. -> Option D

4. Quick Check:

   parent = previous resolver result [OK]

Hint: Remember: parent is previous resolver's output [OK]

Common Mistakes:

• Confusing parent with context
• Thinking parent holds query arguments
• Assuming parent is always the root query

2. Which of the following is the correct way to define a resolver function using the parent argument in GraphQL?

easy

A. resolver(parent, args, context, info) { ... }

B. resolver(args, parent, context, info) { ... }

C. resolver(context, parent, args, info) { ... }

D. resolver(info, args, parent, context) { ... }

Solution

1. Step 1: Recall resolver argument order

   The standard resolver function signature is resolver(parent, args, context, info).

2. Step 2: Verify argument positions

   Only resolver(parent, args, context, info) { ... } matches the correct order with parent as the first argument.

3. Final Answer:

   resolver(parent, args, context, info) { ... } -> Option A

4. Quick Check:

   Parent is first argument in resolver [OK]

Hint: Parent is always first argument in resolver [OK]

Common Mistakes:

• Swapping parent and args positions
• Placing context before parent
• Misordering resolver parameters

3. Given the following GraphQL schema and resolvers, what will be the output of the query { user { id name posts { title } } }?

type User {
  id: ID!
  name: String!
  posts: [Post!]!
}

type Post {
  title: String!
}

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

const postsData = [
  { title: "Post 1", userId: "1" },
  { title: "Post 2", userId: "2" },
  { title: "Post 3", userId: "1" }
];

medium

A. { "user": { "id": "2", "name": "Bob", "posts": [{ "title": "Post 1" }, { "title": "Post 3" }] } }

B. { "user": { "id": "1", "name": "Alice", "posts": [{ "title": "Post 2" }] } }

C. { "user": { "id": "1", "name": "Alice", "posts": [{ "title": "Post 1" }, { "title": "Post 3" }] } }

D. Error: posts resolver missing parent argument

Solution

1. Step 1: Understand parent argument usage in posts resolver

   The posts resolver uses parent.id to filter posts belonging to the user.

2. Step 2: Match posts with user id "1"

   Posts with userId === "1" are "Post 1" and "Post 3".

3. Final Answer:

   { "user": { "id": "1", "name": "Alice", "posts": [{ "title": "Post 1" }, { "title": "Post 3" }] } } -> Option C

4. Quick Check:

   Parent.id filters posts correctly [OK]

Hint: Parent holds user data to filter posts [OK]

Common Mistakes:

• Ignoring parent.id and returning all posts
• Mixing user IDs in filtering
• Assuming posts resolver lacks parent argument

4. Identify the error in this resolver function using the parent argument:

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

medium

A. The resolver should not use filter on postsData.

B. The resolver is missing the parent argument as the first parameter.

C. The resolver should use context instead of args.

D. The resolver function name should be Posts with uppercase P.

Solution

1. Step 1: Check resolver function parameters

   The resolver function must have parent as the first argument to access parent data.

2. Step 2: Identify misuse of args instead of parent

   The code incorrectly uses args.id instead of parent.id to filter posts.

3. Final Answer:

   The resolver is missing the parent argument as the first parameter. -> Option B

4. Quick Check:

   Parent argument must be first in resolver [OK]

Hint: Always include parent as first resolver argument [OK]

Common Mistakes:

• Using args instead of parent for parent data
• Ignoring resolver parameter order
• Assuming function name case matters

5. You want to fetch a list of books with their authors' names using nested resolvers. The Book type has an authorId field, and the Author type has id and name. How should you use the parent argument in the author resolver inside Book to get the correct author name?

hard

A. Use parent.authorId to find the author by matching id.

B. Use args.authorId to find the author by matching id.

C. Use context.authorId to find the author by matching id.

D. Use info.authorId to find the author by matching id.

Solution

1. Step 1: Understand nested resolver data flow

   The author resolver inside Book receives the book object as parent.

2. Step 2: Access authorId from parent to find author

   Use parent.authorId to look up the author by matching id in authors data.

3. Final Answer:

   Use parent.authorId to find the author by matching id. -> Option A

4. Quick Check:

   Parent holds book data, use parent.authorId [OK]

Hint: Parent holds book; use parent.authorId for author lookup [OK]

Common Mistakes:

• Using args instead of parent for authorId
• Trying to get authorId from context or info
• Ignoring parent argument in nested resolver