Hvordan bygger du et GraphQL API med NestJS?

Question

Accepted Answer

NestJS har førsteklasses **GraphQL**-støtte via `@nestjs/graphql` (bygget på Apollo Server). Det tilbyr en **code-first**-tilnærming (definer skjemaet ditt med TypeScript-klasser og dekoratorer, skjemaet genereres automatisk) — den idiomatiske NestJS-måten — som passer til frameworkets dekorator/DI-modell.

## Oppsett av GraphQL (code-first)

```ts
@Module({
  imports: [
    GraphQLModule.forRoot<ApolloDriverConfig>({
      driver: ApolloDriver,
      autoSchemaFile: "schema.gql",   // code-first: auto-generate the schema from classes
      playground: true,                // interactive query explorer in dev
    }),
  ],
})
export class AppModule {}
```

## Objekttyper (skjemaet, definert med dekoratorer)

```ts
@ObjectType()                        // a GraphQL type
export class User {
  @Field(() => ID) id: string;
  @Field() name: string;
  @Field() email: string;
  @Field(() => [Post]) posts: Post[];   // related type
}
```

I code-first definerer dekorerte klasser (`@ObjectType`, `@Field`) skjemaet — TypeScript-typer genererer GraphQL-skjemaet automatisk, og holder dem synkronisert.

## Resolvers (queries og mutations)

```ts
@Resolver(() => User)
export class UsersResolver {
  constructor(private usersService: UsersService) {}   // DI works as usual

@Query(() => [User])               // a query: returns a list of users
  users() {
    return this.usersService.findAll();
  }

@Query(() => User)
  user(@Args("id") id: string) {     // query with an argument
    return this.usersService.findOne(id);
  }

@Mutation(() => User)              // a mutation: creates a user
  createUser(@Args("input") input: CreateUserInput) {
    return this.usersService.create(input);
  }
}
```

Resolvers (som kontrollere, men for GraphQL) definerer `@Query` og `@Mutation`-håndtakere, som delegerer til tjenester via DI — de samme mønstrene som REST-kontrollere.

## Løsing av relaterte felt (unngå N+1-problemet)

```ts
@ResolveField(() => [Post])         // resolve User.posts on demand
posts(@Parent() user: User) {
  return this.postsService.findByUser(user.id);
}
// ⚠️ for lists, this can cause N+1 queries → use DataLoader to BATCH them
```

`@ResolveField` løser relaterte/nestede felt latent — men for lister risikerer dette **N+1-queryproblemet**, løst med DataLoader-batching.

## GraphQL vs REST avveiinger

```text
GraphQL: clients request EXACTLY the fields they need (no over/under-fetching),
         one endpoint, strongly typed, great for complex/nested data & varied clients
REST:    simpler, better HTTP caching, well-understood — fine for straightforward APIs
→ Choose based on needs, not hype. NestJS supports both equally well.
```

## Hvorfor det betyr noe

NestJS's førsteklasses GraphQL-støtte er verdifull fordi den bringer GraphQLs fordeler — klienter som henter nøyaktig dataene de trenger (eliminerer over- og under-henting), et enkelt sterkt typet endepunkt, og utmerket håndtering av kompleks/nestet data — inn i NestJS's kjente, strukturerte modell.

Å forstå det er viktig for å bygge moderne APIer, spesielt den idiomatiske **code-first-tilnærmingen** (definere skjemaet med TypeScript-klasser og `@ObjectType`/`@Field`/`@Resolver`-dekoratorer, med skjemaet som genereres automatisk og holdes synkronisert) som naturlig passer til NestJS's dekorator/DI-arkitektur — resolvers fungerer akkurat som kontrollere, og delegerer til injiserte tjenester.

Å vite hvordan du definerer typer, queries, mutations og løste felt, og være klar over **N+1-queryproblemet** (og DataLoader som løsningen) for nestet data, er nøkkelkunnskap på seniorplan.

Like viktig er det å forstå **GraphQL vs REST-avveiningene** for å velge riktig tilnærming for et gitt prosjekt (GraphQL for fleksibel, kompleks, multi-klient datbehov; REST for enklere APIer med sterk HTTP-caching).

GraphQL er et større API-paradigme, og NestJS's rene integrasjon gjør det til en betydelig, hyppig relevant evne for å bygge fleksible, effektive back-ender.