NestJS tem suporte GraphQL de primeira classe via @nestjs/graphql (construído sobre Apollo Server). Oferece uma abordagem code-first (defina seu schema com classes e decoradores TypeScript, schema gerado automaticamente) — a forma idiomática do NestJS — adequada ao modelo de decorator/DI do framework.
({
: [
.<>({
: ,
: ,
: ,
}),
],
})
{}
@ObjectType() // a GraphQL type
export class User {
@Field(() => ID) id: string;
@Field() name: string;
@Field() email: string;
@Field(() => [Post]) posts: Post[]; // related type
}
No code-first, classes decoradas (@ObjectType, @Field) definem o schema — tipos TypeScript geram o schema GraphQL automaticamente, mantendo-os sincronizados.
@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 (como controllers, mas para GraphQL) definem handlers @Query e @Mutation, delegando para serviços via DI — os mesmos padrões que controllers 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 resolve campos relacionados/aninhados de forma lazy — mas para listas, isso corre o risco do problema de query N+1, resolvido com batching de 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.
O suporte GraphQL de primeira classe do NestJS é valioso porque traz os benefícios do GraphQL — clientes buscando exatamente os dados que precisam (eliminando over- e under-fetching), um único endpoint fortemente tipado, e excelente tratamento de dados complexos/aninhados — no modelo familiar e estruturado do NestJS.
/Entender isso é importante para construir APIs modernas, especialmente a abordagem idiomática code-first (definindo o schema com classes TypeScript e decoradores @ObjectType/@Field/@Resolver, com o schema gerado automaticamente e mantido em sincronização) que se adequa naturalmente à arquitetura decorator/DI do NestJS — resolvers funcionam como controllers, delegando para serviços injetados.
Saber como definir tipos, queries, mutations e campos resolvidos, e estar ciente do problema de query N+1 (e DataLoader como solução) para dados aninhados, é conhecimento essencial de nível sênior.
Equalmente importante é entender os trade-offs GraphQL vs REST para escolher a abordagem correta para um determinado projeto (GraphQL para dados flexíveis, complexos, com múltiplos clientes; REST para APIs mais simples com caching HTTP forte).
GraphQL é um paradigma de API importante, e a integração limpa do NestJS o torna uma capacidade significativa e frequentemente relevante para construir back-ends flexíveis e eficientes.