NestJS ha un supporto GraphQL di prima classe tramite @nestjs/graphql (basato su Apollo Server). Offre un approccio code-first (definisci lo schema con classi TypeScript e decorator, lo schema viene generato automaticamente) — il modo idiomatico di NestJS — che si adatta al modello decorator/DI del framework.
({
: [
.<>({
: ,
: ,
: ,
}),
],
})
{}
@ObjectType() // a GraphQL type
export class User {
@Field(() => ID) id: string;
@Field() name: string;
@Field() email: string;
@Field(() => [Post]) posts: Post[]; // related type
}
Nel code-first, le classi decorate (@ObjectType, @Field) definiscono lo schema — i tipi TypeScript generano automaticamente lo schema GraphQL, mantenendoli sincronizzati.
@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);
}
}
I resolver (come i controller, ma per GraphQL) definiscono handler @Query e @Mutation, delegando ai servizi tramite DI — gli stessi pattern dei controller REST.
@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 risolve campi annidati/correlati in modo lazy — ma per le liste, questo rischia il problema della query N+1, risolto con il batching DataLoader.
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.
Il supporto GraphQL di prima classe di NestJS è prezioso perché porta i benefici di GraphQL — i client recuperano esattamente i dati di cui hanno bisogno (eliminando over- e under-fetching), un singolo endpoint fortemente tipizzato, e un'ottima gestione di dati complessi/annidati — nel modello familiare e strutturato di NestJS.
\
Capirlo è importante per costruire API moderne, in particolare l'approccio idiomatico code-first (definire lo schema con classi TypeScript e decorator @ObjectType/@Field/@Resolver, con lo schema generato automaticamente e mantenuto sincronizzato) che si adatta naturalmente all'architettura decorator/DI di NestJS — i resolver funzionano proprio come i controller, delegando ai servizi iniettati.
Sapere come definire i tipi, le query, le mutation e i campi risolti, ed essere consapevoli del problema della query N+1 (e DataLoader come soluzione) per i dati annidati, è conoscenza chiave a livello senior.
Egualmente importante è comprendere i trade-off tra GraphQL e REST per scegliere l'approccio giusto per un determinato progetto (GraphQL per esigenze di dati flessibili, complesse e multi-client; REST per API più semplici con strong HTTP caching).
GraphQL è un paradigma API importante, e l'integrazione pulita di NestJS lo rende una capacità significativa e frequentemente rilevante per costruire back-end flessibili ed efficienti.