NestJS میں @nestjs/graphql کے ذریعے GraphQL کی پہلی درجہ کی support ہے (Apollo Server پر مبنی)۔ یہ code-first approach پیش کرتا ہے (اپنے schema کو TypeScript classes اور decorators سے define کریں، schema خودکار طور پر تیار ہوتا ہے) — یہ NestJS کا idiomatic طریقہ ہے — جو framework کے decorator/DI ماڈل کے ساتھ موافق ہے۔
({
: [
.<>({
: ,
: ,
: ,
}),
],
})
{}
@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 کو define کرتے ہیں — TypeScript types خودکار طور پر GraphQL schema تیار کرتے ہیں، انہیں synchronize رکھتے ہوئے۔
@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 define کرتے ہیں، DI کے ذریعے services کو delegate کرتے ہیں — 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 کو سست طریقے سے resolve کرتا ہے — لیکن lists کے لیے، یہ N+1 query problem کا خطرہ رکھتا ہے، جو 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 کی first-class GraphQL support قیمتی ہے کیونکہ یہ GraphQL کے فوائد لاتی ہے — clients بالکل وہی ڈیٹا حاصل کرتے ہیں جن کی انہیں ضرورت ہے (over- اور under-fetching کو ختم کرتے ہوئے)، ایک single strongly-typed endpoint، اور پیچیدہ/nested ڈیٹا کی بہترین handling — NestJS کے واقف، structured model میں۔
اس کو سمجھنا اہم ہے جدید APIs بنانے کے لیے، خاص طور پر idiomatic code-first approach (TypeScript classes اور @ObjectType/@Field/@Resolver decorators کے ساتھ schema define کرنا، schema خودکار طور پر تیار اور synchronize رہتا ہے) جو NestJS کے decorator/DI architecture کے ساتھ قدرتی طریقے سے فٹ بیٹھتا ہے — resolvers بالکل controllers کی طرح کام کرتے ہیں، injected services کو delegate کرتے ہیں۔
جاننا ضروری ہے کہ types، queries، mutations، اور resolved fields کو کیسے define کریں، اور N+1 query problem (اور DataLoader حل کے طور پر) سے nested ڈیٹا کے لیے آگاہ ہوں، یہ senior-level علم کی کلید ہے۔
برابر اہم GraphQL بمقابلہ REST trade-offs کو سمجھنا ہے کسی دیے گئے project کے لیے صحیح approach منتخب کرنے کے لیے (GraphQL لچکدار، پیچیدہ، multi-client ڈیٹا کی ضروریات کے لیے؛ REST سادہ APIs کے لیے مضبوط HTTP caching کے ساتھ)۔
GraphQL ایک بڑا API paradigm ہے، اور NestJS کی صاف integration اسے ایک اہم، بار بار relevant صلاحیت بناتی ہے لچکدار، موثر back-ends بنانے کے لیے۔
تفصیلی جوابات کے ساتھ IT انٹرویو سوالات کی ایک لائبریری — جونیئر سے سینئر تک۔
عطیہ دیں