Fragments for reusable selections in GraphQL - Step-by-Step Execution

Concept Flow - Fragments for reusable selections

Define Fragment

↓

Use Fragment in Query

↓

GraphQL Server Expands Fragment

↓

Execute Query with Expanded Fields

↓

Return Data with Reused Fields

You first define a fragment with reusable fields, then include it in queries. The server replaces the fragment with its fields before running the query.

Execution Sample

GraphQL

fragment userFields on User {
  id
  name
  email
}

query getUsers {
  users {
    ...userFields
  }
}

Defines a fragment 'userFields' with common user fields, then uses it inside a query to fetch users with those fields.

Execution Table

Step	Action	Fragment Expansion	Query Fields	Result Data
1	Define fragment 'userFields'	N/A	N/A	N/A
2	Start query 'getUsers'	N/A	users { ...userFields }	N/A
3	Expand fragment in query	id, name, email	users { id, name, email }	N/A
4	Execute query with expanded fields	N/A	users { id, name, email }	[{"id":1, "name":"Alice", "email":"[e-mail]"}, {"id":2, "name":"Bob", "email":"[e-mail]"}]
5	Return data to client	N/A	N/A	Same as step 4

💡 Query completes after expanding fragments and fetching requested fields.

Variable Tracker

Variable	Start	After Step 3	After Step 4	Final
Fragment 'userFields'	Not defined	Defined with id, name, email	Used in query expansion	Used in final query
Query fields	users { ...userFields }	users { id, name, email }	Executed with these fields	Returned data matches these fields
Result data	Empty	Empty	[{"id":1, "name":"Alice", "email":"[e-mail]"}, {"id":2, "name":"Bob", "email":"[e-mail]"}]	Returned to client

Key Moments - 2 Insights

Why do we define fragments separately instead of writing fields directly in the query?

Fragments let you reuse the same set of fields in many places, avoiding repetition and mistakes. See step 1 and 3 in the execution_table where the fragment is defined once and then expanded.

Does the server send the fragment name in the response?

No, the server replaces the fragment with its fields before running the query, so the response only contains the actual data fields. See step 4 and 5 where the result data has fields but no fragment names.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the fragment expanded into actual fields?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Check the 'Fragment Expansion' column in the execution_table.

According to variable_tracker, what fields does the fragment 'userFields' include after step 3?

A name, email

B id, name

C id, name, email

D id, email

💡 Hint

Look at the 'Fragment 'userFields'' row under 'After Step 3' in variable_tracker.

If you add a new field 'age' to the fragment, what changes in the execution_table?

A Step 3's Fragment Expansion will include 'age'

B Step 4's Result Data will exclude 'age'

C Step 2 will show 'age' in query fields

D No changes anywhere

💡 Hint

Fragments control which fields are expanded in step 3.

Concept Snapshot

Fragments let you define reusable sets of fields.
Syntax: fragment Name on Type { fields }
Use with ...Name inside queries.
Server replaces fragments with fields before execution.
Helps avoid repeating field lists in multiple queries.

Full Transcript

Fragments in GraphQL are reusable pieces of field selections. You define a fragment with a name and a set of fields on a type. Then, inside queries, you use the fragment by prefixing its name with three dots. The GraphQL server expands these fragments by replacing them with their field lists before running the query. This way, you avoid repeating the same fields in many queries. The response only contains the actual data fields, not the fragment names. This makes queries cleaner and easier to maintain.