Default resolvers in GraphQL - Step-by-Step Execution

Concept Flow - Default resolvers

GraphQL Query Received

↓

Check Field Resolver

↓

Use Custom

↓

Fetch Data

↓

Return Result

When a GraphQL query runs, it looks for a custom resolver for each field. If none is found, it uses the default resolver which returns the field value from the parent object.

Execution Sample

GraphQL

query {
  user {
    id
    name
  }
}

This query asks for a user's id and name. If no custom resolver exists for 'id' or 'name', default resolvers return those fields from the user object.

Execution Table

Step	Field	Custom Resolver?	Action	Result
1	user	No	Use default resolver to get 'user' object	{ id: 1, name: "Alice" }
2	id	No	Use default resolver to get 'id' from user object	1
3	name	No	Use default resolver to get 'name' from user object	"Alice"
4	Query complete	-	-	Return { user: { id: 1, name: "Alice" } }

💡 All fields resolved; query result assembled and returned.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
user	undefined	{ id: 1, name: "Alice" }	{ id: 1, name: "Alice" }	{ id: 1, name: "Alice" }	{ id: 1, name: "Alice" }
id	undefined	undefined	1	1	1
name	undefined	undefined	undefined	"Alice"	"Alice"

Key Moments - 2 Insights

Why does the default resolver return the field value from the parent object?

Because when no custom resolver is defined (see execution_table steps 2 and 3), the default resolver simply looks up the field name in the parent object and returns its value.

What happens if a custom resolver exists for a field?

If a custom resolver exists (not shown in this example), GraphQL calls that resolver function instead of the default one to get the field's value.

Visual Quiz - 3 Questions

Look at the execution table, what is the result of resolving the 'name' field at step 3?

A 1

B undefined

C "Alice"

D Error

💡 Hint

Check the 'Result' column for step 3 in the execution_table.

At which step does the 'user' object get fetched using the default resolver?

A Step 2

B Step 1

C Step 3

D Step 4

💡 Hint

Look at the 'Field' and 'Action' columns in the execution_table.

If a custom resolver was added for 'name', how would the execution_table change?

A Step 3 would show 'Yes' under 'Custom Resolver?' and call the custom function.

B Step 2 would change to use the custom resolver.

C Step 1 would return an error.

D No changes; default resolver always runs.

💡 Hint

Recall the concept_flow where custom resolvers override default ones.

Concept Snapshot

Default resolvers in GraphQL automatically return the field's value from the parent object if no custom resolver is defined.
When a query runs, each field checks for a custom resolver.
If none exists, the default resolver returns parent[fieldName].
This simplifies schema design by avoiding boilerplate for simple fields.
Custom resolvers are only needed for computed or complex fields.

Full Transcript

When a GraphQL query is executed, each field is resolved by checking if a custom resolver function exists. If it does, that function is called to get the field's value. If not, the default resolver is used, which simply returns the value of the field from the parent object. For example, in a query requesting a user's id and name, if no custom resolvers exist for these fields, the default resolver returns the 'id' and 'name' properties from the user object. This process continues for all fields until the full query result is assembled and returned. This behavior allows simple fields to be resolved automatically without extra code, while still supporting custom logic when needed.