NestJS में @nestjs/graphql (Apollo Server पर निर्मित) के माध्यम से प्रथम-श्रेणी GraphQL समर्थन है। यह एक code-first दृष्टिकोण प्रदान करता है (अपने schema को TypeScript classes और decorators से परिभाषित करें, schema स्वतः-उत्पन्न होता है) — आदर्श NestJS तरीका — जो framework के decorator/DI model में फिट बैठता है।
({
: [
.<>({
: ,
: ,
: ,
}),
],
})
{}
@ObjectType() // a GraphQL type
export class User {
@Field(() => ID) id: string;
@Field() name: string;
@Field() email: string;
@Field(() => [Post]) posts: Post[]; // related type
}
code-first में, decorated classes (@ObjectType, @Field) schema को परिभाषित करती हैं — TypeScript types स्वचालित रूप से GraphQL schema उत्पन्न करती हैं, जिससे वे sync में रहती हैं।
@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 (controllers की तरह, पर GraphQL के लिए) @Query और @Mutation handlers परिभाषित करते हैं, DI के माध्यम से services को सौंपते हुए — REST controllers के समान patterns।
@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 संबंधित/nested fields को आलस्यपूर्वक (lazily) resolve करता है — पर lists के लिए, यह N+1 query समस्या का जोखिम पैदा करता है, जिसे DataLoader batching से हल किया जाता है।
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.
NestJS का प्रथम-श्रेणी GraphQL समर्थन मूल्यवान है क्योंकि यह GraphQL के लाभों — clients का ठीक वही data fetch करना जिसकी उन्हें ज़रूरत हो (over- और under-fetching को समाप्त करते हुए), एक एकल strongly-typed endpoint, और जटिल/nested data का उत्कृष्ट प्रबंधन — को NestJS के परिचित, संरचित model में लाता है।
इसे समझना आधुनिक APIs बनाने के लिए महत्वपूर्ण है, विशेष रूप से आदर्श code-first दृष्टिकोण (schema को TypeScript classes और @ObjectType/@Field/@Resolver decorators से परिभाषित करना, schema स्वतः-उत्पन्न और sync में रखा जाता है) जो NestJS के decorator/DI architecture में स्वाभाविक रूप से फिट बैठता है — resolvers बिल्कुल controllers की तरह काम करते हैं, injected services को सौंपते हुए।
Types, queries, mutations, और resolved fields कैसे परिभाषित करें यह जानना, और nested data के लिए N+1 query समस्या (और इसके समाधान के रूप में DataLoader) से अवगत होना प्रमुख senior-स्तरीय ज्ञान है।
समान रूप से महत्वपूर्ण है किसी दिए गए project के लिए सही दृष्टिकोण चुनने हेतु GraphQL बनाम REST के व्यापार-समझौतों को समझना (लचीली, जटिल, बहु-client data आवश्यकताओं के लिए GraphQL; मज़बूत HTTP caching वाले सरल APIs के लिए REST)।
GraphQL एक प्रमुख API प्रतिमान है, और NestJS का स्वच्छ एकीकरण इसे लचीले, कुशल back-ends बनाने के लिए एक महत्वपूर्ण, बार-बार प्रासंगिक क्षमता बनाता है।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें