Resolver chains in GraphQL - Time & Space Complexity
When using resolver chains in GraphQL, each resolver calls another to get data. We want to understand how the total work grows as we add more linked resolvers.
How does the time to get the final data change when the chain gets longer?
Analyze the time complexity of the following code snippet.
query {
user(id: "1") {
posts {
comments {
text
}
}
}
}
// Each field calls a resolver that fetches related data.
// user resolver fetches user info.
// posts resolver fetches posts for that user.
// comments resolver fetches comments for each post.
This query uses resolver chains: user -> posts -> comments. Each resolver depends on the previous one's result.
Look for repeated work in the chain.
- Primary operation: For each post, fetching its comments.
- How many times: Number of posts times number of comments per post.
As the number of posts and comments grows, the total work grows too.
| Input Size (posts x comments) | Approx. Operations |
|---|---|
| 10 posts x 5 comments | 50 fetches |
| 100 posts x 5 comments | 500 fetches |
| 100 posts x 20 comments | 2000 fetches |
Pattern observation: The total operations grow roughly by multiplying posts and comments counts.
Time Complexity: O(p × c)
This means the time grows with the number of posts times the number of comments per post.
[X] Wrong: "Each resolver runs once, so time is just O(n) where n is total fields."
[OK] Correct: Because some resolvers run multiple times--once per item in a list--so total time multiplies by list sizes.
Understanding resolver chains helps you explain how nested data fetching impacts performance. This skill shows you can reason about real-world GraphQL queries and their costs.
"What if the comments resolver used batching to fetch all comments at once? How would the time complexity change?"