What are field resolvers in NestJS GraphQL and when do you use them instead of fetching all data in the root query?

Q: What are field resolvers in NestJS GraphQL and when do you use them instead of fetching all data in the root query?

@Resolver(() => User) export class UsersResolver { constructor( private usersService: UsersService, private postsService: PostsService, ) {} @Query(() => [User]) users() { return this.usersService.findAll(); } // Only executes when client requests user.posts // parent = the User object resolved by the root query @ResolveField(() => [Post]) async posts(@Parent() user: User): Promise { return this.postsService.findByUserId(user.id); } // Computed field — not stored in the database @ResolveField(() => String) fullName(@Parent() user: User): string { return `${user.firstName} ${user.lastName}`; } } Field resolvers are lazy — they only execute when the client explicitly requests that field. Without field resolvers every user query would eagerly load posts even when not needed. This is GraphQL's core efficiency advantage over REST — you only pay for data you request. @Parent() injects the parent object (the resolved User) so you can use its ID for the sub-query. Field resolvers are the primary integration point for DataLoader to solve the N+1 problem.

Difficulty: 6/10

field resolvers, lazy loading, performance optimization

A field resolver is decorated with @ResolveField() and lazily resolves a single field on a parent type. It only executes when that specific field is actually requested by the client. Use field resolvers for related data that requires a separate fetch — this avoids over-fetching when clients do not need the related data.

Field resolver with @Parent() decorator

Why field resolvers matter:

1
Field resolvers are lazy — they only execute when the client explicitly requests that field.
2
Without field resolvers every user query would eagerly load posts even when not needed.
3

What are field resolvers in NestJS GraphQL and when do you use them instead of fetching all data in the root query?

Difficulty: 6/10

field resolvers, lazy loading, performance optimization

A field resolver is decorated with @ResolveField() and lazily resolves a single field on a parent type. It only executes when that specific field is actually requested by the client. Use field resolvers for related data that requires a separate fetch — this avoids over-fetching when clients do not need the related data.

Field resolver with @Parent() decorator

Why field resolvers matter:

1
Field resolvers are lazy — they only execute when the client explicitly requests that field.
2
Without field resolvers every user query would eagerly load posts even when not needed.
3

What are field resolvers in NestJS GraphQL and when do you use them instead of fetching all data in the root query?

What are field resolvers in NestJS GraphQL and when do you use them instead of fetching all data in the root query?

Scenario Questions

Follow-up Questions