Single endpoint architecture in GraphQL - Time & Space Complexity
When using a single endpoint in GraphQL, we want to know how the time to get data changes as the request asks for more information.
We ask: How does the work grow when the query asks for more fields or nested data?
Analyze the time complexity of the following GraphQL query structure.
query GetUserData($userId: ID!) {
user(id: $userId) {
id
name
posts {
id
title
comments {
id
content
}
}
}
}
This query fetches a user, their posts, and comments on each post in one request to a single GraphQL endpoint.
Look for repeated data fetching steps inside the query.
- Primary operation: Fetching posts and comments for each post.
- How many times: For each post, comments are fetched, so nested loops happen over posts and comments.
As the number of posts and comments grows, the work to fetch all data grows too.
| Input Size (n posts, m comments each) | Approx. Operations |
|---|---|
| 10 posts, 5 comments each | About 10 + (10 x 5) = 60 operations |
| 100 posts, 5 comments each | About 100 + (100 x 5) = 600 operations |
| 1000 posts, 5 comments each | About 1000 + (1000 x 5) = 6000 operations |
Pattern observation: The total work grows roughly in proportion to the number of posts times the number of comments per post.
Time Complexity: O(n x m)
This means the time to get data grows with the number of posts times the number of comments per post.
[X] Wrong: "The single endpoint means the query always takes the same time regardless of data size."
[OK] Correct: Even with one endpoint, the server must fetch all requested nested data, so more posts and comments mean more work.
Understanding how nested data requests affect time helps you explain performance in real projects and shows you can think about efficient data fetching.
What if the query requested only the user and posts, but not comments? How would the time complexity change?