Response caching strategies in GraphQL - Step-by-Step Execution

Concept Flow - Response caching strategies

Client sends GraphQL query

↓

Check cache for query response

↓

Return cached

↓

Send response

↓

Client receives response

The flow shows how a GraphQL server checks if a query response is cached before running resolvers, returning cached data if available, or executing and caching the response if not.

Execution Sample

GraphQL

query GetUser {
  user(id: "1") {
    id
    name
  }
}

A client requests user data by ID; the server checks cache before resolving.

Execution Table

Step	Action	Cache Hit?	Cache Store	Response Sent
1	Receive query GetUser with id=1	No	No	No
2	Check cache for query response	No	No	No
3	Execute resolver to fetch user data	No	No	No
4	Store response {id:1, name:'Alice'} in cache	No	Yes	No
5	Send response to client	No	Yes	Yes
6	Receive same query again	Yes	Yes	No
7	Return cached response	Yes	Yes	Yes

💡 Execution stops after sending response to client.

Variable Tracker

Variable	Start	After Step 2	After Step 4	After Step 7
cache	{}	{}	{"GetUser(id:1)": {"id": "1", "name": "Alice"}}	{"GetUser(id:1)": {"id": "1", "name": "Alice"}}
responseSent	false	false	false	true

Key Moments - 3 Insights

Why does the server check the cache before executing the resolver?

Checking the cache first avoids unnecessary resolver execution, saving time and resources, as shown in execution_table step 2 where cache is checked before running the resolver.

What happens if the cache does not have the response?

The server executes the resolver to get fresh data, then stores it in the cache for future use, as seen in steps 3 and 4.

How does the server know when to send the cached response?

If the cache has the response (cache hit), the server sends it immediately without running resolvers, as shown in step 7.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the response stored in the cache?

A Step 4

B Step 2

C Step 6

D Step 7

💡 Hint

Check the 'Cache Store' column in execution_table rows.

At which step does the server send the cached response to the client?

A Step 3

B Step 7

C Step 5

D Step 1

💡 Hint

Look at the 'Cache Hit?' and 'Response Sent' columns in execution_table.

If the cache was empty, what would happen at step 2?

A Cache hit, return cached response

B Send error response

C Cache miss, execute resolver

D Ignore query

💡 Hint

Refer to the 'Cache Hit?' column and subsequent actions in execution_table.

Concept Snapshot

Response caching in GraphQL:
- Check cache before running resolvers
- If cache hit, return cached response immediately
- If cache miss, execute resolver and store response
- Improves performance by reducing resolver calls
- Cache keys often based on query and variables

Full Transcript

This visual execution shows how a GraphQL server handles response caching. When a client sends a query, the server first checks if the response is already cached. If yes, it returns the cached response immediately, saving time. If not, it runs the resolver to get fresh data, stores this response in the cache, then sends it to the client. Variables like 'cache' track stored responses, and 'responseSent' tracks if the client got the data. Key moments include understanding why cache is checked first, what happens on cache miss, and how cached responses are returned. The quiz questions help reinforce these steps by referencing the execution table and variable states.

Practice

1. What is the main purpose of response caching in GraphQL?

easy

A. To store query results and speed up repeated requests

B. To encrypt data sent between client and server

C. To validate user permissions for queries

D. To log all queries for debugging

Solution

1. Step 1: Understand response caching concept

   Response caching saves the answers of queries so that if the same query is asked again, the server can quickly return the saved answer instead of recalculating it.

2. Step 2: Identify the main benefit

   This speeds up repeated requests and reduces server load.

3. Final Answer:

   To store query results and speed up repeated requests -> Option A

4. Quick Check:

   Response caching = store and speed up [OK]

Hint: Caching saves answers to reuse later, speeding up requests [OK]

Common Mistakes:

• Confusing caching with encryption
• Thinking caching controls permissions
• Believing caching logs queries

2. Which of the following is the correct way to set a cache duration using the @cacheControl directive in GraphQL SDL?

easy

A. @cacheControl(duration: 60)

B. @cacheControl(maxAge: 60)

C. @cacheControl(cacheTime: 60)

D. @cacheControl(time: 60)

Solution

1. Step 1: Recall the correct directive syntax

   The @cacheControl directive uses the argument maxAge to specify cache duration in seconds.

2. Step 2: Match the correct argument name

   Only maxAge is valid; other argument names like duration, cacheTime, or time are incorrect.

3. Final Answer:

   @cacheControl(maxAge: 60) -> Option B

4. Quick Check:

   @cacheControl uses maxAge [OK]

Hint: Use maxAge to set cache seconds in @cacheControl [OK]

Common Mistakes:

• Using wrong argument names like duration or time
• Omitting the argument name
• Using invalid directive syntax

3. Given this GraphQL query with caching set to @cacheControl(maxAge: 120), what happens if the same query is requested twice within 2 minutes?

medium

A. The server returns the cached response on the second request

B. The server returns an error on the second request

C. The server recalculates the response both times

D. The cache is ignored and data is fetched fresh every time

Solution

1. Step 1: Understand maxAge meaning

   The maxAge: 120 means the response is cached for 120 seconds (2 minutes).

2. Step 2: Analyze repeated request timing

   If the second request happens within 2 minutes, the cached response is still valid and returned immediately.

3. Final Answer:

   The server returns the cached response on the second request -> Option A

4. Quick Check:

   maxAge 120 means cache valid 2 minutes [OK]

Hint: Within maxAge, cached response is reused [OK]

Common Mistakes:

• Thinking cache expires immediately
• Assuming server errors on repeated queries
• Believing cache is ignored always

4. You set @cacheControl(maxAge: -10) on a field. What is the likely problem?

medium

A. Negative maxAge causes a syntax error

B. Negative maxAge disables caching for that field

C. Negative maxAge is treated as zero, caching forever

D. Negative maxAge causes cache to expire immediately

Solution

1. Step 1: Understand maxAge value meaning

   maxAge defines how long the response is cached in seconds. Negative values are invalid for duration.

2. Step 2: Interpret negative maxAge effect

   Negative maxAge is treated as cache expired immediately, so no caching occurs effectively.

3. Final Answer:

   Negative maxAge causes cache to expire immediately -> Option D

4. Quick Check:

   Negative maxAge means cache expires instantly [OK]

Hint: Negative maxAge means cache expires right away [OK]

Common Mistakes:

• Expecting syntax error from negative value
• Thinking negative disables caching explicitly
• Assuming negative means cache forever

5. You want to cache a GraphQL query response for a user profile that updates frequently but not every second. Which caching strategy is best?

hard

A. Set @cacheControl(maxAge: 5) to cache for 5 seconds

B. Set @cacheControl(maxAge: 3600) to cache for 1 hour

C. Set @cacheControl(maxAge: 300) to cache for 5 minutes

D. Do not use caching to always get fresh data

Solution

1. Step 1: Consider data freshness needs

   User profiles update frequently but not every second, so caching too long risks stale data.

2. Step 2: Choose a balanced cache duration

   5 seconds is too short to gain caching benefits; 1 hour is too long risking stale data. 5 minutes (300 seconds) balances freshness and performance.

3. Final Answer:

   Set @cacheControl(maxAge: 300) to cache for 5 minutes -> Option C

4. Quick Check:

   Moderate maxAge balances freshness and speed [OK]

Hint: Pick cache time balancing freshness and speed [OK]

Common Mistakes:

• Choosing too short cache time losing benefits
• Choosing too long cache time causing stale data
• Avoiding caching when moderate caching helps