Resolvers in NestJS - Performance & Optimization

Performance: Resolvers

MEDIUM IMPACT

Resolvers impact server response time and client perceived latency by controlling how data is fetched and processed before sending to the client.

Fetching nested data in GraphQL queries

NestJS

async user() {
  const user = await this.userService.findUserWithPosts();
  return user;
}

Fetches user and posts in a single optimized query, reducing round trips and latency.

📈 Performance GainSingle database query; response ready faster; reduces server processing time

Fetching nested data in GraphQL queries

NestJS

async user() {
  const user = await this.userService.findUser();
  user.posts = await Promise.all(user.postIds.map(id => this.postService.findPostById(id)));
  return user;
}

This pattern triggers multiple parallel database calls for each nested item, causing high latency and blocking response.

📉 Performance CostBlocks response until all nested calls complete; triggers N database queries for N posts

Performance Comparison

Pattern	Server Calls	Latency Impact	Network Payload	Verdict
Multiple nested calls per resolver	Many sequential calls	High latency	Larger payload due to delays	[X] Bad
Single optimized query per resolver	One call with joins	Low latency	Smaller, timely payload	[OK] Good

Rendering Pipeline

Resolvers run on the server before the browser rendering pipeline starts. Slow resolvers delay data delivery, which delays browser rendering and LCP.

→Server Data Fetching

→Network Transfer

→Browser Rendering

⚠️ BottleneckServer Data Fetching due to inefficient resolver logic or multiple nested calls

Core Web Vital Affected

LCP

Resolvers impact server response time and client perceived latency by controlling how data is fetched and processed before sending to the client.

Optimization Tips

1Avoid multiple sequential database calls in resolvers to reduce latency.

2Use batching and optimized queries to fetch nested data efficiently.

3Faster resolver responses improve Largest Contentful Paint and user experience.

Performance Quiz - 3 Questions

What is a common performance issue with naive resolver implementations in NestJS GraphQL?

A Using a single optimized database query

B Caching data at the client side

C Making multiple sequential database calls for nested data

D Using static data instead of dynamic queries

DevTools: Network

How to check: Open DevTools Network tab, trigger the GraphQL query, and inspect the response time and payload size.

What to look for: Look for long waiting times (TTFB) indicating slow resolver processing and large payloads delaying LCP.

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