Node interface pattern in GraphQL - Step-by-Step Execution

Concept Flow - Node interface pattern

Client sends query with node ID

↓

Server receives node ID

↓

Resolve node by ID

↓

Find User

↓

Return User

↓

Return Node with __typename

↓

Client receives node

The Node interface pattern lets clients fetch any object by a global ID. The server resolves the ID to the correct type and returns the object with its type info.

Execution Sample

GraphQL

query {
  node(id: "user-1") {
    __typename
    id
    ... on User {
      name
    }
  }
}

This query asks for a node by ID 'user-1', requesting its type, id, and if it's a User, its name.

Execution Table

Step	Action	Input	Process	Output
1	Receive query	node(id: "user-1")	Parse query and extract ID	ID extracted: 'user-1'
2	Resolve node	'user-1'	Look up object by ID	Found User object with id 'user-1'
3	Determine type	User object	Set __typename to 'User'	__typename: 'User'
4	Fetch fields	User object	Retrieve id and name fields	id: 'user-1', name: 'Alice'
5	Return response	Collected data	Package data with __typename	{ __typename: 'User', id: 'user-1', name: 'Alice' }
6	End	Response sent	No more steps	Query complete

💡 Query ends after returning the resolved node with its type and requested fields.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
queryID	null	"user-1"	"user-1"	"user-1"	"user-1"	"user-1"
resolvedNode	null	null	{type: 'User', id: 'user-1', name: 'Alice'}	{type: 'User', id: 'user-1', name: 'Alice'}	{type: 'User', id: 'user-1', name: 'Alice'}	{type: 'User', id: 'user-1', name: 'Alice'}
__typename	null	null	null	"User"	"User"	"User"
response	null	null	null	null	{ __typename: 'User', id: 'user-1', name: 'Alice' }	{ __typename: 'User', id: 'user-1', name: 'Alice' }

Key Moments - 3 Insights

Why do we need the __typename field in the response?

The __typename tells the client what type of object was returned (User, Post, etc.). This helps the client know which fields to expect and how to handle the data, as shown in step 3 of the execution_table.

What happens if the ID does not match any object?

If no object matches the ID, the resolve step (step 2) returns null, and the node field in the response will be null, indicating no object found.

How does the server know which type to return for a given ID?

The server uses the ID format or a lookup table to find the object and its type, as shown in step 2 where 'user-1' resolves to a User object.

Visual Quiz - 3 Questions

Look at the execution_table, what is the __typename value at step 3?

A null

B "User"

C "Post"

D "Node"

💡 Hint

Check the 'Determine type' action in step 3 of the execution_table.

At which step does the server fetch the specific fields like 'name' for the User?

A Step 4

B Step 3

C Step 2

D Step 5

💡 Hint

Look for the step labeled 'Fetch fields' in the execution_table.

If the query asked for a Post node instead of a User, which step would change?

A Step 1 - Receive query

B Step 3 - Determine type

C Step 2 - Resolve node

D Step 6 - End

💡 Hint

Refer to step 2 where the object is found by ID; the type depends on the resolved object.

Concept Snapshot

Node interface pattern in GraphQL:
- Use a global ID to fetch any object.
- Server resolves ID to specific type (User, Post, etc.).
- Response includes __typename for client to identify type.
- Enables flexible, unified querying of different object types.
- Commonly used for Relay-compliant APIs.

Full Transcript

The Node interface pattern allows clients to request any object by a global ID. The server receives the ID, looks up the object, determines its type, and returns the object with a __typename field. This helps clients know what type of object they received and what fields to expect. For example, a query asking for node(id: "user-1") returns a User object with its id and name. The execution steps include receiving the query, resolving the node by ID, determining the type, fetching requested fields, and returning the response. If the ID does not match any object, the node field returns null. This pattern simplifies fetching different types of objects through a single interface.