Code-first GraphQL, resolvers and DataLoader

Code-first: the schema is generated from your classes

In the code-first approach you never hand-write SDL. You decorate TypeScript classes with @ObjectType() and @Field(), decorate resolver methods with @Query() / @Mutation() / @ResolveField(), and Nest generates the schema from that type information at startup. autoSchemaFile writes the SDL to disk (or keeps it in memory) so tooling can read it — but the source of truth is your code. The schema-first alternative is the inverse: you write the SDL by hand and generate the TypeScript typings from it. Code-first wins when your team lives in TypeScript and wants the types and the schema to never drift apart.

import { ApolloDriver, ApolloDriverConfig } from '@nestjs/apollo';
import { GraphQLModule } from '@nestjs/graphql';
import { Module } from '@nestjs/common';

@Module({
  imports: [
    GraphQLModule.forRoot<ApolloDriverConfig>({
      driver: ApolloDriver,
      autoSchemaFile: 'schema.gql',        // GENERATE SDL from the TS classes
      playground: false,                    // off in prod
      introspection: process.env.NODE_ENV !== 'production', // hide the schema in prod
    }),
  ],
})
export class AppModule {}

The object types are plain classes; @Field(() => Int) pins the GraphQL scalar where TS reflection can’t infer it (numbers, arrays, nullability):

import { Field, Int, ObjectType } from '@nestjs/graphql';

@ObjectType()
export class Post {
  @Field(() => Int) id: number;
  @Field() title: string;
}

@ObjectType()
export class Author {
  @Field(() => Int) id: number;
  @Field({ nullable: true }) firstName?: string;
  @Field(() => [Post]) posts: Post[];   // a relation -> resolved lazily by a field resolver
}

Resolvers and the field resolver — where the N+1 is born

A @Resolver(() => Author) class hosts the root operations (@Query, @Mutation) and, crucially, field resolvers (@ResolveField) that compute a field lazily, per parent object. The posts field on Author is not loaded with the author — it is resolved only if the query asks for it, by calling the field resolver once for every author in the result set. That per-parent execution is exactly the N+1: one query for N authors, then N separate queries for their posts.

import { Resolver, Query, ResolveField, Parent, Args, Int } from '@nestjs/graphql';

@Resolver(() => Author)
export class AuthorsResolver {
  constructor(
    private readonly authors: AuthorsService,
    private readonly posts: PostsService,
  ) {}

  @Query(() => [Author])
  authors() {
    return this.authors.findAll();          // 1 query -> N authors
  }

  @ResolveField(() => [Post])
  async postsFor(@Parent() author: Author) {
    return this.posts.findByAuthorId(author.id); // fires ONCE PER AUTHOR -> the N+1
  }
}

DataLoader: batch the keys collected in one tick

DataLoader sits between the field resolver and the database. Instead of querying immediately, every load(id) call enqueues a key; at the end of the current event-loop tick, DataLoader hands the whole batch of keys to one findByAuthorIds([...]) and fans the result back out to each caller. It also memoises within the batch, so two load(5) calls hit the DB once. The collapse is dramatic: 1 + N queries become 1 + 1.

The loader must be per request — its cache holds request data and must never leak across users — so wire it as a request-scoped provider and resolve it in the GraphQL context:

import * as DataLoader from 'dataloader';
import { Injectable, Scope } from '@nestjs/common';

@Injectable({ scope: Scope.REQUEST })   // a fresh loader per request -> no cross-request cache
export class PostsLoader {
  constructor(private readonly posts: PostsService) {}

  readonly byAuthorId = new DataLoader<number, Post[]>(async (authorIds) => {
    // ONE round-trip for every key collected in this tick:
    const rows = await this.posts.findByAuthorIds(authorIds as number[]);
    const byId = new Map<number, Post[]>(authorIds.map((id) => [id, []]));
    for (const p of rows) byId.get(p.authorId)!.push(p);
    return authorIds.map((id) => byId.get(id)!); // MUST return results in key order
  });
}

@ResolveField(() => [Post])
postsFor(@Parent() author: Author) {
  return this.loader.byAuthorId.load(author.id); // enqueue a key; batched, not per-call
}

The batch function’s contract is strict: it must return an array the same length and order as the input keys, mapping a missing key to [] (or null), never silently dropping it — get the order wrong and authors get each other’s posts.

Context, guards, and production hardening

Guards, interceptors, and filters still work in GraphQL — but if you try to use them exactly as you would in an HTTP controller, you’ll find they silently fail to read request args. The resolver argument shape differs (root, args, context, info), so you adapt the generic ExecutionContext with GqlExecutionContext.create(context) to read args or the request:

import { GqlExecutionContext } from '@nestjs/graphql';
import { CanActivate, ExecutionContext, Injectable } from '@nestjs/common';

@Injectable()
export class GqlAuthGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    const ctx = GqlExecutionContext.create(context);
    const { req } = ctx.getContext();   // the request lives on the GraphQL context
    return Boolean(req?.user);
  }
}

A single endpoint that accepts arbitrary queries is a denial-of-service surface: a deeply nested posts { author { posts { author ... } } } can explode into millions of field resolves. Production graphs cap this with a query depth limit and a complexity budget — assign each field a cost and reject any operation over a ceiling before it executes:

import { Plugin } from '@nestjs/apollo';
import { GraphQLSchemaHost } from '@nestjs/graphql';
import { GraphQLError } from 'graphql';
import { fieldExtensionsEstimator, getComplexity, simpleEstimator } from 'graphql-query-complexity';

@Plugin()
export class ComplexityPlugin {
  constructor(private readonly schemaHost: GraphQLSchemaHost) {}
  async requestDidStart() {
    const max = 20, { schema } = this.schemaHost;
    return {
      didResolveOperation: async ({ request, document }) => {
        const complexity = getComplexity({
          schema, query: document, variables: request.variables,
          operationName: request.operationName,
          estimators: [fieldExtensionsEstimator(), simpleEstimator({ defaultComplexity: 1 })],
        });
        if (complexity > max) throw new GraphQLError(`Query too complex: ${complexity} > ${max}`);
      },
    };
  }
}

Add persisted queries (clients send a hash of a pre-registered query, not arbitrary text) and disable introspection in prod so attackers can’t trivially map the whole graph.