Bird
Raised Fist0
NestJSframework~8 mins

Queries and mutations in NestJS - Performance & Optimization

Choose your learning style10 modes available
Performance: Queries and mutations
MEDIUM IMPACT
This concept affects the speed of data fetching and updating on the client side, impacting how fast the UI responds and renders new data.
Fetching data with GraphQL queries and updating data with mutations in NestJS
NestJS
import { Resolver, Query, Mutation, Args } from '@nestjs/graphql';

@Resolver()
export class UserResolver {
  @Query(() => [User])
  async users(@Args('limit', { nullable: true }) limit?: number, @Args('offset', { nullable: true }) offset?: number) {
    // Fetch users with pagination
    return this.userService.findPaginated(limit ?? 10, offset ?? 0);
  }

  @Mutation(() => User)
  async updateUser(@Args('id') id: string, @Args('input') input: UpdateUserInput) {
    // Validate input and batch updates if possible
    return this.userService.update(id, input);
  }
}
Pagination reduces data size per request improving load speed. Validations and batching reduce server calls and improve mutation responsiveness.
📈 Performance GainReduces data transfer size; lowers server processing time; improves INP by faster query and mutation responses.
Fetching data with GraphQL queries and updating data with mutations in NestJS
NestJS
import { Resolver, Query, Mutation, Args } from '@nestjs/graphql';

@Resolver()
export class UserResolver {
  @Query(() => [User])
  async users() {
    // Fetch all users without pagination or filtering
    return this.userService.findAll();
  }

  @Mutation(() => User)
  async updateUser(@Args('id') id: string, @Args('input') input: UpdateUserInput) {
    // Update user and return updated user
    return this.userService.update(id, input);
  }
}
Fetching all users without pagination or filtering causes large data loads, slowing response and rendering. Mutation updates without validation or batching can cause multiple slow server calls.
📉 Performance CostBlocks UI rendering until full data loads; triggers multiple server round-trips; increases INP due to slow responses.
Performance Comparison
PatternDOM OperationsReflowsPaint CostVerdict
Fetch all data without paginationHigh (large data causes many DOM nodes)Multiple (each data update triggers reflow)High (large repaint area)[X] Bad
Fetch data with pagination and filteringLow (smaller data set)Single or few (batched updates)Low (smaller repaint area)[OK] Good
Rendering Pipeline
Queries and mutations trigger network requests that affect the browser's rendering pipeline by delaying data availability for rendering and interaction updates.
→Network
→JavaScript Execution
→Layout
→Paint
⚠️ BottleneckNetwork latency and server processing time delay data arrival, blocking JavaScript updates and subsequent layout and paint.
Core Web Vital Affected
INP
This concept affects the speed of data fetching and updating on the client side, impacting how fast the UI responds and renders new data.
Optimization Tips
1Always paginate or filter queries to limit data size.
2Batch mutations when possible to reduce network calls.
3Validate and optimize input to avoid unnecessary server processing.
Performance Quiz - 3 Questions
Test your performance knowledge
What is a main performance benefit of using pagination in GraphQL queries?
AIncreases server load by making more requests
BDelays UI updates by batching data
CReduces data size per request, speeding up response and rendering
DTriggers more reflows in the browser
DevTools: Network and Performance panels
How to check: Open DevTools, go to Network panel, observe query and mutation request sizes and timings. Then use Performance panel to record interaction and see delays in scripting and rendering.
What to look for: Look for large payload sizes, long server response times, and scripting delays that block UI updates indicating slow queries or mutations.

Practice

(1/5)
1. In NestJS GraphQL, which decorator is used to define a method that fetches data without modifying it?
easy
A. @Query
B. @Mutation
C. @ResolveField
D. @Subscription

Solution

  1. Step 1: Understand the purpose of @Query

    The @Query decorator marks a method as a GraphQL query, which fetches data without changing it.
  2. Step 2: Differentiate from @Mutation

    @Mutation is used for methods that change data, so it is not correct here.
  3. Final Answer:

    @Query -> Option A
  4. Quick Check:

    Fetch data = @Query [OK]
Hint: Queries fetch data, use @Query decorator [OK]
Common Mistakes:
  • Confusing @Mutation with @Query
  • Using @ResolveField for queries
  • Thinking @Subscription fetches data
2. Which of the following is the correct syntax to define a mutation method named createUser in a NestJS GraphQL resolver?
easy
A. @Mutation\ncreateUser() { /*...*/ }
B. @Query(() => User)\ncreateUser() { /*...*/ }
C. @Mutation(() => User)\ncreateUser() { /*...*/ }
D. @Mutation()\ncreateUser() { /*...*/ }

Solution

  1. Step 1: Check decorator usage with return type

    The correct syntax uses @Mutation with a function returning the GraphQL type, e.g., @Mutation(() => User).
  2. Step 2: Verify method name and decorator match

    The method name is createUser, and it must be decorated with @Mutation, not @Query.
  3. Final Answer:

    @Mutation(() => User)\ncreateUser() { /*...*/ } -> Option C
  4. Quick Check:

    Mutation with return type syntax = @Mutation(() => User)\ncreateUser() { /*...*/ } [OK]
Hint: Use @Mutation(() => ReturnType) for mutations [OK]
Common Mistakes:
  • Omitting the return type function in decorator
  • Using @Query instead of @Mutation
  • Adding empty parentheses without return type
3. Given the following NestJS GraphQL resolver code, what will be the output when the getUser query is called?
@Query(() => String)
getUser() {
  return 'Alice';
}
medium
A. Error: Return type mismatch
B. "Alice"
C. null
D. undefined

Solution

  1. Step 1: Analyze the @Query return type and method

    The method getUser returns the string 'Alice' and is decorated with @Query(() => String), matching the return type.
  2. Step 2: Determine the GraphQL response

    GraphQL will return the string value "Alice" as the query result.
  3. Final Answer:

    "Alice" -> Option B
  4. Quick Check:

    Matching return type returns value correctly [OK]
Hint: Return value matches @Query type, so output is that value [OK]
Common Mistakes:
  • Expecting an error due to missing async
  • Confusing return value with null or undefined
  • Thinking GraphQL wraps string differently
4. Identify the error in this NestJS GraphQL mutation resolver code:
@Mutation(() => Boolean)
async updateUser() {
  this.userService.update();
  return true;
}
medium
A. Incorrect return type Boolean instead of boolean
B. updateUser method must return void
C. Mutation should not be async
D. Missing await before userService.update()

Solution

  1. Step 1: Check async method and service call

    The method is async but calls userService.update() without await, so the update may not complete before returning.
  2. Step 2: Understand the impact of missing await

    Without await, the mutation returns true immediately, possibly before update finishes, causing unexpected behavior.
  3. Final Answer:

    Missing await before userService.update() -> Option D
  4. Quick Check:

    Async method must await async calls [OK]
Hint: Always await async calls inside async mutations [OK]
Common Mistakes:
  • Ignoring missing await in async methods
  • Confusing Boolean with boolean types
  • Thinking async is not allowed in mutations
5. You want to create a NestJS GraphQL mutation that updates a user's email and returns the updated user object. Which of the following resolver method signatures correctly combines input argument and mutation decorator?
hard
A. @Mutation(() => User) updateEmail(@Args('email') email: string) { return this.userService.updateEmail(email); }
B. @Query(() => User) updateEmail(@Args('email') email: string) { return this.userService.updateEmail(email); }
C. @Mutation(() => User) updateEmail(email: string) { return this.userService.updateEmail(email); }
D. @Mutation(() => User) updateEmail(@Args() email: string) { return this.userService.updateEmail(email); }

Solution

  1. Step 1: Confirm correct decorator for data change

    Since this method updates data, it must use @Mutation with the return type User.
  2. Step 2: Check argument decorator usage

    The argument email is correctly decorated with @Args('email') to extract the argument from GraphQL input.
  3. Step 3: Verify method signature correctness

    @Mutation(() => User) updateEmail(@Args('email') email: string) { return this.userService.updateEmail(email); } correctly combines @Mutation, return type, and @Args usage.
  4. Final Answer:

    @Mutation(() => User) updateEmail(@Args('email') email: string) { return this.userService.updateEmail(email); } -> Option A
  5. Quick Check:

    Mutation with @Args('email') and return type = @Mutation(() => User) updateEmail(@Args('email') email: string) { return this.userService.updateEmail(email); } [OK]
Hint: Use @Mutation with @Args('argName') for input arguments [OK]
Common Mistakes:
  • Using @Query for mutations
  • Omitting @Args decorator
  • Using @Args() without argument name
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard