Resolvers in NestJS

Introduction

Resolvers help your app answer questions from users by connecting requests to the right data or actions.

When you want to handle GraphQL queries and mutations in your NestJS app.

When you need to fetch or change data based on user requests.

When you want to organize how your app responds to different GraphQL operations.

When you want to keep your code clean by separating data fetching logic.

When building APIs that use GraphQL to communicate with clients.

Syntax

NestJS

import { Resolver, Query, Mutation, Args } from '@nestjs/graphql';

@Resolver()
export class ExampleResolver {
  @Query(() => String)
  sayHello(): string {
    return 'Hello!';
  }

  @Mutation(() => Boolean)
  updateData(@Args('input') input: string): boolean {
    // update logic here
    return true;
  }
}

@Resolver marks the class as a GraphQL resolver.

@Query and @Mutation decorate methods to handle GraphQL queries and mutations.

Examples

This resolver answers a simple query that returns a greeting string.

NestJS

import { Resolver, Query } from '@nestjs/graphql';

@Resolver()
export class SimpleResolver {
  @Query(() => String)
  greet() {
    return 'Hi there!';
  }
}

This resolver handles a mutation that changes a status and returns true if successful.

NestJS

import { Resolver, Mutation, Args } from '@nestjs/graphql';

@Resolver()
export class UpdateResolver {
  @Mutation(() => Boolean)
  changeStatus(@Args('status') status: string) {
    // pretend to update status
    return true;
  }
}

Sample Program

This resolver stores a message string. You can get the current message with a query, or change it with a mutation.

NestJS

import { Resolver, Query, Mutation, Args } from '@nestjs/graphql';

@Resolver()
export class MessageResolver {
  private message = 'Hello World';

  @Query(() => String)
  getMessage() {
    return this.message;
  }

  @Mutation(() => String)
  setMessage(@Args('newMessage') newMessage: string) {
    this.message = newMessage;
    return this.message;
  }
}

Important Notes

Resolvers should be simple and focused on handling one type of data or action.

Use @Args to get input values from GraphQL queries or mutations.

Keep your resolver methods fast and avoid heavy processing inside them.

Summary

Resolvers connect GraphQL requests to your app's data or actions.

Use @Resolver, @Query, and @Mutation decorators to define them.

Resolvers help keep your code organized and easy to understand.

Practice

1. What is the main purpose of a @Resolver in a NestJS GraphQL application?

easy

A. To handle GraphQL queries and mutations by connecting them to data or actions

B. To define database schemas for the application

C. To manage HTTP routes and middleware

D. To style the frontend components

Solution

1. Step 1: Understand the role of @Resolver

   The @Resolver decorator marks a class that handles GraphQL queries and mutations, linking them to the app's data or business logic.

2. Step 2: Differentiate from other roles

   It does not define database schemas, manage HTTP routes, or style frontend components, which are handled by other parts of the app.

3. Final Answer:

   To handle GraphQL queries and mutations by connecting them to data or actions -> Option A

4. Quick Check:

   Resolver purpose = handle GraphQL queries/mutations [OK]

Hint: Resolvers link GraphQL requests to your app's data/actions [OK]

Common Mistakes:

• Confusing resolvers with database schema definitions
• Thinking resolvers manage HTTP routes
• Assuming resolvers handle frontend styling

2. Which of the following is the correct way to define a GraphQL query resolver method in NestJS?

easy

A. @Controller()
getHello() {
return 'Hello World';
}

B. @Mutation(() => String)
getHello() {
return 'Hello World';
}

C. @Query(() => String)
getHello() {
return 'Hello World';
}

D. @Resolver(() => String)
getHello() {
return 'Hello World';
}

Solution

1. Step 1: Identify the decorator for queries

   In NestJS GraphQL, @Query decorator is used to define query resolver methods.

2. Step 2: Check method syntax

   The method returns a string and is decorated with @Query(() => String), which is correct syntax.

3. Final Answer:

   @Query(() => String) getHello() { return 'Hello World'; } -> Option C

4. Quick Check:

   Query method uses @Query decorator [OK]

Hint: Use @Query for queries, @Mutation for mutations [OK]

Common Mistakes:

• Using @Mutation instead of @Query for queries
• Using @Resolver on methods instead of classes
• Using @Controller which is for REST, not GraphQL

3. Given this resolver code, what will be the output when the hello query is called?

@Resolver()
export class HelloResolver {
  @Query(() => String)
  hello() {
    return 'Hi NestJS';
  }
}

medium

A. Error: Missing return type

B. "Hello World"

C. null

D. "Hi NestJS"

Solution

1. Step 1: Analyze the resolver method

   The hello method is decorated with @Query(() => String) and returns the string 'Hi NestJS'.

2. Step 2: Determine the query output

   When the hello query is called, it returns the string exactly as coded: 'Hi NestJS'.

3. Final Answer:

   "Hi NestJS" -> Option D

4. Quick Check:

   Query returns 'Hi NestJS' string [OK]

Hint: Return value inside @Query method is the output [OK]

Common Mistakes:

• Expecting 'Hello World' instead of 'Hi NestJS'
• Thinking a return type error occurs
• Assuming null is returned by default

4. Identify the error in this NestJS resolver code:

@Resolver()
export class SampleResolver {
  @Query(() => String)
  sample() {
    return 123;
  }
}

medium

A. The method returns a number but the return type is declared as String

B. Missing @Mutation decorator

C. The class is missing @Injectable decorator

D. The method name should be capitalized

Solution

1. Step 1: Check the return type annotation

   The @Query(() => String) decorator declares the return type as String.

2. Step 2: Check the actual return value

   The method returns the number 123, which conflicts with the declared String return type.

3. Final Answer:

   The method returns a number but the return type is declared as String -> Option A

4. Quick Check:

   Return type mismatch causes error [OK]

Hint: Return type must match decorator type [OK]

Common Mistakes:

• Ignoring return type mismatch
• Thinking @Mutation is needed for queries
• Assuming @Injectable is required on resolvers

5. You want to create a resolver that returns a list of users filtered by an optional age argument. Which code snippet correctly implements this in NestJS?

hard

A. @Resolver()
export class UserResolver {
@Mutation(() => [User])
users(@Args('age') age: number) {
return users.filter(u => u.age === age);
}
}

B. @Resolver()
export class UserResolver {
@Query(() => [User])
users(@Args('age', { nullable: true }) age?: number) {
return age ? users.filter(u => u.age === age) : users;
}
}

C. @Resolver()
export class UserResolver {
@Query(() => User)
users(@Args('age') age: number) {
return users.find(u => u.age === age);
}
}

D. @Resolver()
export class UserResolver {
@Query(() => [User])
users() {
return users;
}
}

Solution

1. Step 1: Check the query decorator and return type

   The method uses @Query(() => [User]) which correctly indicates it returns a list of users.

2. Step 2: Verify optional argument handling

   The @Args('age', { nullable: true }) age?: number allows the age argument to be optional, filtering users if provided, or returning all users otherwise.

3. Step 3: Confirm filtering logic

   The method filters the users array by age if age is given, otherwise returns all users, matching the requirement.

4. Final Answer:

   @Resolver() export class UserResolver { @Query(() => [User]) users(@Args('age', { nullable: true }) age?: number) { return age ? users.filter(u => u.age === age) : users; } } -> Option B

5. Quick Check:

   @Resolver() export class UserResolver { @Query(() => [User]) users(@Args('age', { nullable: true }) age?: number) { return age ? users.filter(u => u.age === age) : users; } } [OK]

Hint: Use nullable args for optional filters in @Query [OK]

Common Mistakes:

• Using @Mutation instead of @Query for fetching data
• Returning single User instead of list
• Not making argument optional when needed