NestJS má prvotřídní GraphQL podporu prostřednictvím @nestjs/graphql (postavenou na Apollo Server). Nabízí code-first přístup (definujete schéma pomocí tříd a dekorátorů TypeScriptu, schéma se automaticky generuje) — idiomatický způsob NestJS, který se hodí k modelu dekorátorů a DI frameworku.
({
: [
.<>({
: ,
: ,
: ,
}),
],
})
{}
@ObjectType() // a GraphQL type
export class User {
@Field(() => ID) id: string;
@Field() name: string;
@Field() email: string;
@Field(() => [Post]) posts: Post[]; // related type
}
V code-first přístupu dekorované třídy (@ObjectType, @Field) definují schéma — TypeScript typy automaticky generují GraphQL schéma, čímž je zajišťuje jejich synchronizace.
@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);
}
}
Resolvery (podobně jako kontrolery, ale pro GraphQL) definují handlery @Query a @Mutation, delegují na služby prostřednictvím DI — stejné vzory jako REST kontrolery.
@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 řeší souvisejícího/vnořená pole lenivě — ale pro seznamy to riskuje problém N+1 dotazů, který se řeší dávkováním 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.
Prvotřídní GraphQL podpora NestJS je cenná, protože přináší výhody GraphQL — klienti si načítají přesně ta data, která potřebují (eliminuje over- a under-fetching), jeden silně typizovaný endpoint a vynikající zpracování komplexních/vnořených dat — do známého, strukturovaného modelu NestJS.
Porozumění tomu je důležité pro vytváření moderních API, zvláště idiomatického code-first přístupu (definování schématu pomocí tříd TypeScriptu a dekorátorů @ObjectType/@Field/@Resolver, se schématem automaticky generovaným a udržovaným v synchronizaci), který přirozeně odpovídá architektuře dekorátorů a DI NestJS — resolvery fungují stejně jako kontrolery, delegují na injektované služby.
Znalost definování typů, queries, mutations a vyřešených polí a vědomí problému N+1 dotazů (a DataLoader jako řešení) pro vnořená data je klíčová znalost na úrovni seniora.
Rovnocenně důležité je porozumění kompromisům GraphQL vs REST pro výběr správného přístupu pro daný projekt (GraphQL pro flexibilní, komplexní, multi-klientské datové potřeby; REST pro jednodušší API se silným HTTP cachingem).
GraphQL je velkým paradigmatem API a čistá integrace NestJS jej činí významnou, často relevantní schopností pro vytváření flexibilních, efektivních back-endů.