Why Resolvers in NestJS? - Purpose & Use Cases

The Big Idea

Discover how resolvers turn complex request handling into simple, organized code!

The Scenario

Imagine building a server that must handle many different requests, each needing specific data fetched and processed manually.

You write separate functions for each request type and manually connect them to routes.

The Problem

This manual approach quickly becomes messy and hard to maintain.

Every time you add a new request type, you must write more boilerplate code and carefully link it to the right route.

It's easy to make mistakes, and debugging becomes a nightmare.

The Solution

Resolvers in NestJS let you neatly organize how your server responds to different GraphQL queries and mutations.

They automatically connect your data-fetching logic to the right GraphQL operations, reducing boilerplate and errors.

Before vs After

✗ Before

app.get('/user', (req, res) => { /* fetch user manually */ });

✓ After

@Resolver()
export class UserResolver {
  @Query()
  getUser() { /* fetch user */ }
}

What It Enables

Resolvers enable clean, scalable, and easy-to-maintain GraphQL APIs by linking queries and mutations directly to their handling code.

Real Life Example

When building a social media app, resolvers let you easily fetch user profiles, posts, and comments through simple GraphQL queries without messy route handling.

Key Takeaways

Manual request handling is error-prone and hard to scale.

Resolvers organize GraphQL operations cleanly and reduce boilerplate.

They make your API easier to build, read, and maintain.

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