What Is Overfetching?

At the root of why people recommend GraphQL is a concept called overfetching. In many APIs, when you ask about an object the API returns everything it knows, because it doesn't know what you're interested in. GraphQL (like SQL) lets you tell the API specifically what you're after before it makes the inquiry.

It's like walking into a restaurant and asking them to bring everything on the menu to the table, then picking your starter, main course, and dessert. The rest is wasted.

A Practical Example

Consider a query by an imaginary waiter's handheld application:

query foodPricesForOrder {
  menuItem(id: "Jxkjahdkfh==") {
    id
    description
    longDescription
    calories
    price
    picture
  }
}

What if we omitted longDescription? We'd save network traffic, even though the actual database query won't be noticeably quicker if all fields live in the same table.

But notice that picture field — it could be a base64-encoded image. We don't want that on a handheld waiter app. In REST, we'd have no choice but to receive it, or the API developer would have to create a separate endpoint for images. Worse, the REST solution might force the client to make separate calls for every dish.

How GraphQL Solves This

GraphQL lets you ask for just what you need. If a resolver is attached to the picture field (in AppSync, Apollo, or any GraphQL server), it's only triggered when that field appears in the query. As long as you don't include it, you don't pay the price for it.

This is true across the Legalesign API. Fields that require expensive lookups — related objects, computed values, large payloads — only resolve when you ask for them.

The Takeaway

When designing your queries, think about which fields you actually need. Drop anything your UI doesn't use. You'll reduce payload size, network latency, and server-side computation.

See Designing Queries for more practical guidelines.