Resolver Functions Fundamentals

Every Field Is a Function Call You Have Not Written Yet

A schema describes a tree, a document selects a slice of it, and the server still has to produce actual values. Resolvers do that: one function per field, turning inputs into the value that field contributes to the response.

type Query {
  user(id: ID!): User
}

type User {
  id: ID!
  name: String!
  email: String!
}

const resolvers = {
  Query: {
    user: (_root, { id }) => db.users.find(id),
    // returns { id: 1, name: "Ada", email: "ada@example.com" }
  },
  // User.id, User.name, User.email need no code: the default resolver
  // reads the matching property from the parent value.
};

For the document { user(id: "1") { name } } the executor performs exactly two steps:

Query.user(args)  ──►  { id: 1, name: "Ada", email: "ada@example.com" }
                                        │
                             default resolver reads .name
                                        ▼
                        response: { "user": { "name": "Ada" } }

The model to keep: the response is assembled field by field; it is not a serialization of whatever the top resolver returned. That is why a client asking for two fields receives exactly two, and why adding a field to the schema disturbs nothing — it either falls back to the default resolver or gets a function of its own.

It also explains the shape of resolver maps. Keys are type names, then field names:

{ Query: { ... }, Mutation: { ... }, User: { ... }, Post: { ... } }

A resolver declared under the wrong type silently does nothing, and the field falls back to the default — one of the most common "why is this always null" debugging sessions in GraphQL.

The Four Inputs Every Resolver Receives

Every resolver is invoked with the same four arguments, in the same order:

parent is what makes nesting work. Query.user returns a user object, so User.orders receives that object and can query with its id:

const resolvers = {
  Query: {
    user: (_p, { id }, ctx) => ctx.dataSources.users.byId(id),
  },
  User: {
    orders: (user, { first }, ctx) =>
      ctx.dataSources.orders.forUser(user.id, first),
    // user === whatever Query.user returned; nothing more, nothing less
  },
};

If Query.user returned a plain string instead of an object, User.orders would receive that string — resolvers do not know about the schema's intent, only about the value handed to them. The full downward journey of that value is parent argument flow.

context is constructed once per request and shared by every resolver in that execution; resolver context covers what belongs there and the cross-request leak you get by building it too early. args arrives already coerced: types, defaults, and non-null rules were applied during validation.

info is the escape hatch. info.path says where you are (["user", "orders", 3]), info.parentType and info.returnType describe the schema node being filled, and info.fieldNodes holds the raw selection including aliases and directives. Reach for it when building dataloader keys, accounting query cost, or tracing — never as a substitute for arguments the schema already declared.

A resolver does not have to receive all four. (_p, args) => ... is fine when context is unused; positional destructuring keeps signatures honest about what a field actually needs.

Missing Resolvers, Undefined, and Resolver Independence

Three behaviors are worth predicting before you meet them in production.

Field order in the schema and document does not sequence anything. Resolvers run as the executor reaches them, and siblings may execute concurrently. Code that assumes "the field listed first ran first" breaks intermittently under load — what actually overlaps is explained in async resolver patterns.

A missing resolver falls back to the default resolver, which reads parent[fieldName]:

// schema: type User { nickname: String }
resolveDefault({ nickname: "ada" }, "nickname")  // -> "ada"
resolveDefault({ nick: "ada" }, "nickname")       // -> undefined (names differ)

Renamed properties, computed values, or data keyed differently all need an explicit resolver. The default is why plain JSON backends appear to need no resolvers at all — and why renaming a property in an upstream JSON payload silently turns a field null.

undefined becomes null, or an error:

resolver returns undefined  +  field is nullable  ->  "field": null
resolver returns undefined  +  field is String!   ->  field error, null bubbles

The second line is where "this used to work" bugs live: a data source stopped returning a property, the field was non-null, and the whole parent object went null. The bubbling rule itself is resolver error propagation.

Because resolvers are independent functions, they are cheap to unit test — call the function with a hand-made parent, literal args, and a stub context, then assert the return value. No server, no HTTP, and the failure you are chasing reproducers in a file you can step through. The move from stubs to real integrations is database data source wiring.