Advanced GraphQL Vocabulary

A resolver is a function that produces the value for a single field in a GraphQL schema. When a query executes, the server walks the requested tree and invokes the matching resolver for each field, passing arguments, the parent object, and a shared context (e.g. the current user or database connection). Resolvers can fetch from databases, call other services, or compute values. Because each field has its own resolver, GraphQL composes data from many sources, but naive per-field fetching is also the source of the notorious N+1 problem.

The N+1 problem arises when resolving a list of N parent objects causes one initial query for the list and then one additional query per item to fetch a related field — N+1 queries total. For example, fetching 100 posts and then each post's author separately hits the database 101 times. This destroys performance under load. It happens because GraphQL resolvers run independently per field and per item, without inherent batching. The standard fix is to batch and cache these lookups, typically with a DataLoader.

A DataLoader is a per-request utility that solves the N+1 problem by batching and caching data fetches. Instead of issuing a query each time a resolver asks for a key, it collects all keys requested during a tick of the event loop and dispatches a single batched query (e.g. WHERE id IN (...)). It also memoizes results within the request so the same key is never fetched twice. You provide a batch function that maps an array of keys to an array of values. DataLoader is request-scoped to avoid leaking data between users.

Federation is an architecture for building a single, unified GraphQL API out of many independently developed subgraph services. Each team owns a subgraph defining the types and fields it is responsible for, and a gateway (or router) composes them into one supergraph. Types can be extended across services using directives like @key, so one service can add fields to an entity owned by another. The gateway plans queries, fetches from the relevant subgraphs, and stitches the results — enabling teams to scale a large graph without a monolith.

A persisted query replaces sending the full GraphQL query string on every request with a short identifier — typically a hash of the query. The query text is registered with the server ahead of time (or on first use, in Automatic Persisted Queries), and thereafter clients transmit only the hash. This reduces payload size and network overhead, and improves security by letting the server allowlist exactly which operations clients may run, blocking arbitrary or malicious queries. It also enables sending APQ requests over GET for better CDN caching.