Performance and Over/Under-Fetching Tests

GraphQL’s flexibility can impact performance and resource usage in ways that differ from REST. Clients can accidentally or deliberately construct queries that over-fetch data, deeply nest relationships, or under-fetch and require many small follow-up queries. Testing for these patterns helps teams keep GraphQL APIs efficient and robust.

Over-Fetching, Under-Fetching, and Query Cost #

Over-fetching happens when queries request far more fields or nested relationships than needed, increasing payload size and backend work. Under-fetching occurs when queries are too narrow, forcing multiple round trips to gather related data. Many teams introduce query cost analysis or depth limits to detect and control expensive queries.

# Example of a potentially expensive query

query DeepCustomerGraph($id: ID!) {
  customer(id: $id) {
    id
    name
    orders {
      id
      total
      items {
        id
        product {
          id
          name
          reviews {
            id
            rating
            comment
          }
        }
      }
    }
  }
}

Performance testing of GraphQL APIs can reuse many concepts from REST performance testing, such as measuring latency, throughput, and error rates under load. However, the mix of queries and their shapes matters more, because a few expensive queries can dominate resource usage.

Designing Performance-Oriented GraphQL Tests #

Create representative query sets that mirror real client behaviour, including typical, heavy, and intentionally pathological queries. Measure response times and resource usage, and confirm that protections like timeouts, depth limits, and rate limiting behave as expected. Use these results to guide schema and resolver optimisations.

Common Mistakes #

Mistake 1 — Testing performance only with trivial queries #

This underestimates real-world load.

❌ Wrong: Load testing only a simple { ping } query.

✅ Correct: Include complex, nested queries that resemble real usage.

Mistake 2 — Ignoring query complexity controls #

Without limits, APIs may be vulnerable to expensive queries.

❌ Wrong: Never testing how the server handles deep or costly queries.

✅ Correct: Design tests that approach or exceed configured limits and verify safe behaviour.