Info argument in GraphQL - Step-by-Step Execution

Concept Flow - Info argument

GraphQL Query Received

↓

Resolver Function Called

↓

Info Argument Passed

↓

Info Contains Query Details

↓

Resolver Uses Info to Access Query AST

↓

Resolver Returns Data Based on Info

↓

Response Sent to Client

The info argument is passed to resolver functions and contains details about the GraphQL query, allowing resolvers to understand the query structure and fields requested.

Execution Sample

GraphQL

const resolver = (parent, args, context, info) => {
  console.log(info.fieldName);
  return 'Hello';
};

This resolver logs the field name requested in the query using the info argument and returns a simple string.

Execution Table

Step	Action	info.fieldName	Result
1	GraphQL query calls resolver for 'greeting' field	greeting	Resolver starts execution
2	Resolver logs info.fieldName	greeting	Logs 'greeting' to console
3	Resolver returns 'Hello'	greeting	Response 'Hello' sent to client
4	Execution ends	-	Resolver finished

💡 Resolver returns response and execution ends

Variable Tracker

Variable	Start	After Step 1	After Step 2	Final
info.fieldName	undefined	greeting	greeting	greeting

Key Moments - 2 Insights

Why does info.fieldName contain the name of the field being resolved?

Because the GraphQL engine passes the info argument to the resolver with details about the current field, as shown in execution_table step 1 and 2.

Can the info argument be used to access the full query structure?

Yes, info contains the query's abstract syntax tree (AST), allowing the resolver to inspect requested fields beyond just the current one.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of info.fieldName at step 2?

A undefined

B Hello

C greeting

D null

💡 Hint

Check the 'info.fieldName' column in execution_table row for step 2

At which step does the resolver return the response to the client?

A Step 2

B Step 3

C Step 1

D Step 4

💡 Hint

Look at the 'Result' column in execution_table for when the response is sent

If the query requested a field named 'user', what would info.fieldName be at step 2?

A user

B greeting

C args

D context

💡 Hint

info.fieldName matches the field being resolved, see variable_tracker and execution_table

Concept Snapshot

Info argument in GraphQL resolvers:
- Passed as 4th parameter: (parent, args, context, info)
- Contains query details and AST
- info.fieldName shows current field name
- Useful to inspect query structure
- Helps build dynamic responses

Full Transcript

The info argument is a special parameter passed to GraphQL resolver functions. It contains detailed information about the query being executed, including the name of the field currently being resolved, accessible via info.fieldName. This allows the resolver to know exactly which field it is handling. The info argument also includes the full query structure as an abstract syntax tree (AST), enabling advanced use cases like conditional data fetching based on requested fields. In the example, the resolver logs the field name and returns a simple string. The execution table shows each step: receiving the query, calling the resolver, logging info.fieldName, returning the response, and finishing execution. Understanding the info argument helps developers write flexible and efficient resolvers.

Practice

1. What is the purpose of the info argument in a GraphQL resolver?

easy

A. It stores the database connection details.

B. It contains the user's authentication token.

C. It tells the resolver which fields the client requested.

D. It defines the schema of the GraphQL server.

Solution

1. Step 1: Understand the role of resolver arguments

   Resolvers receive arguments like parent, args, context, and info. Each has a specific role.

2. Step 2: Identify what info provides

   The info argument contains details about the query, including which fields the client requested.

3. Final Answer:

   It tells the resolver which fields the client requested. -> Option C

4. Quick Check:

   Info argument = requested fields [OK]

Hint: Info shows requested fields to optimize data fetching [OK]

Common Mistakes:

• Confusing info with context or args
• Thinking info holds authentication data
• Assuming info defines schema

2. Which of the following is the correct way to include the info argument in a GraphQL resolver function?

easy

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

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

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

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

Solution

1. Step 1: Recall the standard resolver signature

   The standard order is (parent, args, context, info) in GraphQL resolvers.

2. Step 2: Match the correct order

   resolver(parent, args, context, info) { ... } matches this order exactly, making it the correct syntax.

3. Final Answer:

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

4. Quick Check:

   Resolver args order = parent, args, context, info [OK]

Hint: Remember resolver args order: parent, args, context, info [OK]

Common Mistakes:

• Mixing up the order of arguments
• Placing info before context
• Omitting info argument

3. Given this resolver snippet, what will info.fieldNodes[0].selectionSet.selections.map(f => f.name.value) return if the client queries { user { id name } }?

medium

A. ["id", "name"]

B. ["user"]

C. ["id"]

D. An empty array []

Solution

1. Step 1: Understand the query structure

   The client requests the fields id and name inside user.

2. Step 2: Analyze the info.fieldNodes access

   info.fieldNodes[0].selectionSet.selections lists the fields requested inside user, which are id and name.

3. Final Answer:

   ["id", "name"] -> Option A

4. Quick Check:

   info.fieldNodes selections = requested fields [OK]

Hint: info.fieldNodes lists requested fields inside current resolver [OK]

Common Mistakes:

• Returning parent field name instead of subfields
• Confusing selectionSet with fieldNodes
• Expecting only one field instead of all requested

4. You wrote this resolver: function resolver(parent, args, context) { return info.fieldNodes; }. Why does this cause an error?

medium

A. You cannot access fieldNodes inside resolvers.

B. The resolver is missing the info argument in its parameters.

C. The info argument must be the first parameter.

D. Resolvers cannot return objects like fieldNodes.

Solution

1. Step 1: Check resolver parameters

   The resolver only has three parameters: parent, args, context. It lacks the fourth parameter info.

2. Step 2: Understand usage of info

   Since info is not declared, trying to use it causes a reference error.

3. Final Answer:

   The resolver is missing the info argument in its parameters. -> Option B

4. Quick Check:

   Missing info param = error [OK]

Hint: Always include info as fourth parameter to use it [OK]

Common Mistakes:

• Forgetting to add info parameter
• Assuming info is global or in context
• Misordering resolver parameters

5. You want your resolver to return only the fields requested by the client to save resources. Which approach using the info argument is best?

hard

A. Fetch all fields but filter results after sending to client.

B. Ignore info and always fetch all fields from the database.

C. Use args to guess which fields the client wants.

D. Use info.fieldNodes to find requested fields and fetch only those from the database.

Solution

1. Step 1: Understand the goal

   The goal is to fetch only requested fields to save resources.

2. Step 2: Use info to get requested fields

   info.fieldNodes provides the exact fields the client asked for, so you can fetch only those.

3. Step 3: Compare options

   Use info.fieldNodes to find requested fields and fetch only those from the database. uses info correctly. Options B, C, and D either waste resources or guess incorrectly.

4. Final Answer:

   Use info.fieldNodes to find requested fields and fetch only those from the database. -> Option D

5. Quick Check:

   Use info to fetch requested fields only [OK]

Hint: Fetch only requested fields using info to save resources [OK]

Common Mistakes:

• Fetching all data regardless of request
• Using args instead of info for fields
• Filtering after fetching all data