GraphQL Resolver Vocabulary

Resolvers are the engine of a GraphQL API — they bridge the schema contract and the data sources.

Resolver function signature:

fieldName(parent, args, context, info) {
  // parent  — the object returned by the parent resolver
  // args    — arguments passed in the query for this field
  // context — shared state (auth user, DB connection, DataLoader instances)
  // info    — schema info (field name, return type, AST of the query)
  return /* data for this field */;
}

Example resolver map:

const resolvers = {
  Query: {
    user: (_, { id }, { db }) => db.users.findById(id),
  },
  User: {
    posts: (user, _, { db }) => db.posts.findByAuthor(user.id),
    // 'user' is the parent — the User object returned by the Query.user resolver
  },
}

Resolver chain execution:
① Query.user resolves — returns a User object
② For each requested field on User (name, email, posts), the User's field resolvers run
③ User.posts resolver uses the parent User object to fetch that user's posts
④ For each Post, the Post field resolvers run in turn

Default resolver: if you don't define a resolver for a field, GraphQL uses a default resolver that reads the field name as a property from the parent object (parent["fieldName"]). This is why simple fields like name and email often don't need explicit resolvers.

Key vocabulary:
• Resolver — a function that returns the value for a specific GraphQL field
• Resolver chain — the tree of resolvers called for a single GraphQL query
• Default resolver — automatically reads the field name as a property from the parent object
• Context — shared resolver state (auth, DB connections, DataLoader instances)

The N+1 problem is the most common performance issue in GraphQL — understanding DataLoader is essential.

What happens without DataLoader:
• Query returns 100 posts → 1 DB query
• For each post, Post.author resolver fires → 100 separate DB queries
• Total: 101 queries for what could be 2 queries
• With 1000 posts: 1001 queries — a severe performance problem

DataLoader solution — batch and deduplicate:

// DataLoader setup (created per request in context)
const userLoader = new DataLoader(async (userIds) => {
  const users = await db.users.findAll({ id: { $in: userIds } });
  return userIds.map(id => users.find(u => u.id === id));
});

// Post.author resolver — uses DataLoader instead of direct DB call
Post: {
  author: (post, _, { userLoader }) => userLoader.load(post.authorId)
}

What DataLoader does:
① Collects all load(authorId) calls during the current tick
② Batches them into a single SELECT * FROM users WHERE id IN (id1, id2, ...id100)
③ Returns the individual results to each resolver
④ Deduplicates: if 50 posts share the same author, the user is fetched once

Result: 2 queries instead of 101

Key vocabulary:
• N+1 problem — 1 query for N objects + N additional queries for related data
• DataLoader — a utility that batches and deduplicates data fetching within a single request tick
• Batch function — the function DataLoader calls with all collected keys at once
• Deduplication — DataLoader's caching so duplicate loads within a request hit the cache, not the DB

The context is the primary mechanism for dependency injection in GraphQL resolvers.

Typical context contents:

// Context created fresh for each incoming request
async function createContext({ req }) {
  const token = req.headers.authorization?.split('Bearer ')[1];
  const user = token ? await verifyJWT(token) : null;

  return {
    user,                          // The authenticated user (or null)
    db,                            // Database connection / ORM
    userLoader: new DataLoader(batchLoadUsers),   // Fresh DataLoader per request
    postLoader: new DataLoader(batchLoadPosts),
    featureFlags: await getFeatureFlags(user?.id),
  };
}

Why fresh per request:
• If you reused a DataLoader across requests, User A's cached data could be returned to User B — a serious security vulnerability
• The authenticated user (context.user) is different for each request
• DataLoader caches are only valid for the duration of a single request

How resolvers use context:

Query: {
  myOrders: (_, __, { user, db }) => {
    if (!user) throw new AuthenticationError('Must be logged in');
    return db.orders.findByUserId(user.id);
  }
}

Security note: Authorisation checks belong in the resolver or a directive — never in the context creation function — so each field can have its own permission model.

Key vocabulary:
• Context — per-request object shared across all resolvers in a single execution
• Request-scoped — a fresh instance created for every incoming request
• Dependency injection — passing dependencies (DB, auth, DataLoader) via context rather than importing globals
• Context leakage — the security bug when per-request data is incorrectly shared between requests

IDOR (Insecure Direct Object Reference) is a critical GraphQL security vulnerability — OWASP API Security Top 10 #1: Broken Object Level Authorisation.

The vulnerability:
Any authenticated user can query user(id: "ANY_USER_ID") and receive full user data, including PII like email addresses, phone numbers, or private settings.

Fixes:

// Option 1: User can only see their own data
Query: {
  user: (_, { id }, { user, db }) => {
    if (!user) throw new AuthenticationError('Not authenticated');
    if (user.id !== id && !user.roles.includes('ADMIN')) {
      throw new ForbiddenError('Access denied');
    }
    return db.users.findById(id);
  }
}

// Option 2: Always return the current user (no id argument needed)
Query: {
  me: (_, __, { user, db }) => {
    if (!user) throw new AuthenticationError('Not authenticated');
    return db.users.findById(user.id);
  }
}

GraphQL-specific authorisation patterns:
• Resolver-level authorisation: check permissions in each resolver (shown above)
• Schema directives: @auth(requires: ADMIN) applied in the SDL
• Middleware libraries: graphql-shield defines permission rules as a separate layer

Key vocabulary:
• IDOR (Insecure Direct Object Reference) — accessing resources by manipulating IDs without authorisation checks
• Object-level authorisation — verifying the user has permission to access the specific object, not just the endpoint
• Broken Object Level Authorisation — OWASP API Security Top 10 #1
• Schema directive — a custom directive in the SDL used for cross-cutting concerns like authorisation

Resolver-level tracing is essential for diagnosing GraphQL performance issues — HTTP-level latency alone doesn't tell you which field is slow.

Why resolver tracing matters:
A query with 50 fields could have one slow resolver (e.g., an un-batched database call in Post.comments) dragging total latency to 3 seconds. Without field-level traces, you only know the query is slow — not which field to fix.

What a resolver trace looks like:

Query.posts           [0ms → 12ms]   ✅ Fast
Post.author (×100)    [12ms → 890ms] ⚠️  N+1 — 100 separate DB calls
Post.title (×100)     [0ms → 0ms]    ✅ Default resolver
Post.comments (×100)  [890ms → 2100ms] ❌ SLOW — missing DataLoader

Tools for GraphQL tracing:
• Apollo Studio (cloud): automatic field-level performance analytics
• opentelemetry-instrumentation-graphql: open-source resolver spans
• graphql-query-complexity: assigns a complexity score to queries — reject queries above a threshold to prevent abuse

Key metrics to track:
• Resolver duration — time each resolver takes to return
• Field error rate — how often a specific field returns an error
• Query depth — nesting level of the query (deep queries can trigger N+1 exponential growth)
• Query complexity — estimated cost of a query, used for rate limiting

Key vocabulary:
• Resolver trace / span — an individual resolver's execution recorded as a timing measurement
• Apollo tracing — the pioneering format for per-field execution timing in GraphQL
• Query complexity — a numeric estimate of a query's computational cost used for abuse prevention
• Depth limiting — rejecting queries that exceed a maximum nesting depth