Resolvers are functions that provide the values requested by GraphQL operations.

Consider this schema:

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

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

A resolver implementation might conceptually look like:

const resolvers = {
  Query: {
    user: async (_, args) => {
      return userRepository.findById(args.id);
    }
  }
};

The schema defines the contract. The resolver provides the behavior.

A resolver can retrieve data from almost anywhere:

• MongoDB
• PostgreSQL
• Redis
• Another REST API
• Another GraphQL API
• An in-memory cache
• A message or event system
• A computed value

Resolvers therefore act as an important boundary between the GraphQL API layer and the application's domain/data layers.

A common architectural mistake is putting all business logic directly inside resolver functions. Resolvers should generally coordinate the request rather than becoming enormous business-service functions.

A resolver function commonly receives four conceptual arguments:

(parent, args, context, info)

The exact function signature can vary by GraphQL server implementation, but these four concepts are fundamental.

Parent

parent contains the value returned by the resolver of the parent field.

Args

args contains arguments supplied to the field.

For:

user(id: "42")

args might be:

{ id: "42" }

Context

context contains request-scoped information shared by resolvers. It is commonly used for authentication information, database clients, loaders, request IDs, or other request-level dependencies.

Info

info contains execution metadata, including information about the current field and GraphQL operation. Advanced tooling and optimization systems can use it.

Example:

const resolvers = {
  Query: {
    user: async (parent, args, context, info) => {
      return context.userService.findById(args.id);
    }
  }
};

Understanding these arguments is essential because they provide the bridge between the GraphQL execution engine and your application.

GraphQL fields can contain nested objects, and nested fields can have their own resolvers.

Consider:

type User {
  id: ID!
  name: String!
  posts: [Post!]!
}

type Post {
  id: ID!
  title: String!
}

A query may request:

query {
  user(id: "42") {
    id
    name
    posts {
      id
      title
    }
  }
}

The Query.user resolver can return a user object. The User.posts resolver can then use that returned object as its parent value.

const resolvers = {
  Query: {
    user: (_, { id }, context) => context.userService.findById(id)
  },
  User: {
    posts: (user, _, context) => {
      return context.postService.findByUserId(user.id);
    }
  }
};

This is one of the most important concepts in GraphQL execution.

The parent resolver does not necessarily have to fetch every nested relation immediately. Each nested field can resolve its own data.

This flexibility can become a performance problem if implemented naively. If a query requests 100 users and each user's posts resolver performs a separate database query, the server can encounter the classic N+1 query problem. DataLoader and batching techniques will be covered later in the course.

Not every field needs an explicit resolver.

Suppose a resolver returns:

{
  id: "42",
  name: "Alice",
  email: "alice@example.com"
}

and the schema contains:

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

GraphQL implementations commonly provide default field resolution behavior that reads matching properties from the parent object.

Conceptually:

User object
   |
   +-- id    → User.id
   +-- name  → User.name
   +-- email → User.email

Therefore, you often only need to explicitly define a resolver for fields requiring special behavior.

For example, if name is already a property on the returned object, an explicit resolver may be unnecessary.

But if the schema field is:

fullName: String!

while the underlying object contains:

{
  firstName: "Alice",
  lastName: "Johnson"
}

you may need a custom resolver:

const resolvers = {
  User: {
    fullName: (user) => `${user.firstName} ${user.lastName}`
  }
};

This default-resolution behavior helps keep resolver maps concise.

GraphQL execution is field-oriented, but the exact execution behavior depends on the operation and server implementation.

A useful conceptual model is that sibling fields can often be resolved independently, while fields that depend on parent objects are resolved after their parent values are available.

For example:

query {
  user(id: "42") {
    id
    name
    posts {
      id
      title
    }
  }
}

The user field must produce the parent object before posts can use that user value. Once an object is available, its selected child fields can be evaluated according to GraphQL's execution semantics.

This matters when writing asynchronous resolvers.

For example:

const resolvers = {
  Query: {
    dashboard: async (_, __, context) => {
      const [profile, notifications] = await Promise.all([
        context.profileService.getProfile(),
        context.notificationService.getNotifications()
      ]);

      return { profile, notifications };
    }
  }
};

Application-level concurrency can reduce latency when independent data sources can safely be queried in parallel.

However, parallel execution is not a reason to fire unlimited database queries. Connection pools, downstream service limits, rate limits, CPU, memory, and query complexity must all be considered.

Later chapters will cover DataLoader, batching, caching, query complexity, and performance controls.