GraphQL servers and performance

A GraphQL server is an execution engine plus a table that maps each field to a function.

In REST, one URL is handled by one function. GraphQL works at a much smaller unit: every field in the schema is produced by a function, called a resolver. A resolver always receives the same four arguments: (parent, args, context, info) — the value the parent field returned, the arguments this field received, one object shared by the whole request (§02), and metadata about the current execution (rarely used). Running a query is a walk down the field tree that starts at the Query root type. A parent field runs first, and its return value is passed to its child fields as parent.

Dozens of resolvers run independently, so they need one place to find the things they all use.

context is an object built when a request arrives. Every resolver in that one request receives the same object: the logged-in user, the database connection, and the DataLoader instances from §04. The words "per request" matter. The object does not survive into the next request, so a user stored there cannot leak into someone else's request, and a cache stored there cannot serve stale data later.

The most common performance problem in a GraphQL server. It is much easier to see once than to describe.

Look again at the resolvers in §01. Post.author queries the database once, every time it runs. That is fine for one post. But what happens when the query is posts { author }? The list has N posts, so the author resolver runs N times: 1 query for the list, plus N queries for the authors. Each resolver only sees its own parent. None of them knows that the others are doing the same work. Watch the counter on the right.

A small open-source library with two mechanisms: batching, and a cache that lives for exactly one request.

DataLoader replaces "each resolver queries on its own" with "collect the ids first, then run one query". When a resolver calls load(id), nothing is queried yet. The id is recorded and a Promise is returned. When the current tick of the event loop finishes, DataLoader takes the recorded ids, removes duplicates, fetches them all with one call to batchLoad([9, 12]), and gives each caller its own row. Inside one request, load(9), load(12), load(9) produces a single query — the repeated 9 is answered from the cache and is not even part of the batch.

The same query again, with the loader in place. Watch where the counter stops:

Chapter 05 showed how a REST response can be cached by the browser, a CDN, or a proxy. GraphQL loses most of that. Here are three ways to get it back.

Recall how REST caching works: a GET request and one URL per resource, so the URL itself is the cache key. A browser, a CDN, or a proxy can look at the URL and decide whether it may reuse a stored response, and an ETag lets the server answer 304 Not Modified with no body at all. The traditional GraphQL setup is different: every query is a POST to the same /graphql URL, and the query text sits in the body. The cache key is gone, the caches in between cannot tell two different queries apart, and HTTP caching stops working. This is a real architectural cost — but there are three practical answers.

{
  "post": {
    "__typename": "Post",
    "id": "1",
    "title": "Meeting GraphQL",
    "author": {
      "__typename": "User",
      "id": "9",
      "name": "Ada"
    }
  }
}

Letting the client choose the shape of the query also lets an attacker choose it. Start by looking at what an expensive query looks like.

Three tasks from the server side: count resolver calls, write a batch function, then act as the gatekeeper.

Eight questions. For the N+1 counting one, work the number out on paper instead of guessing.