NestJS ایک بلٹ ان caching module (@nestjs/cache-manager) فراہم کرتا ہے جو ایک unified API کے ساتھ مختلف stores میں کام کرتا ہے — ڈیفالٹ میں in-memory، یا Redis distributed caching کے لیے multiple instances میں۔ Caching کارکردگی میں نمایاں بہتری لاتا ہے بار بار مہنگے کام سے بچ کر۔
({
: [
.({
: ,
: ,
: ,
}),
],
})
{}
@Controller("products")
@UseInterceptors(CacheInterceptor) // automatically caches GET responses
export class ProductsController {
@Get()
@CacheTTL(30000) // override TTL for this route
findAll() {
return this.productsService.findAll(); // result cached; subsequent GETs are instant
}
}
CacheInterceptor خودکار طور پر GET endpoint responses کو cache کرتا ہے (URL سے keyed) اور دوبارہ requests پر cached نتائج فراہم کرتا ہے — read-heavy endpoints کو cache کرنے کا سب سے سادہ طریقہ۔
@Injectable()
export class ProductsService {
constructor(@Inject(CACHE_MANAGER) private cache: Cache) {}
async getProduct(id: string) {
const cached = await this.cache.get(`product:${id}`); // check cache first
if (cached) return cached; // cache HIT
const product = await this.db.findProduct(id); // cache MISS — fetch
await this.cache.set(`product:${id}`, product, 3600000); // store (1h TTL)
return product;
}
}
CACHE_MANAGER کو inject کرنے سے مکمل control ملتا ہے — get-or-fetch pattern (cache چیک کریں، source پر fallback کریں، نتیجہ محفوظ کریں) مخصوص مہنگے operations کو cache کرنے کے لیے۔
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
وہی API، Redis کے ذریعے backed، تمام app instances میں shared cache دیتا ہے — متعدد instances چلانے کے وقت ضروری ہے (in-memory cache ان کے درمیان shared نہیں ہے)۔
async updateProduct(id: string, data) {
await this.db.update(id, data);
await this.cache.del(`product:${id}`); // INVALIDATE on change → avoid stale data
}
The biggest caching challenge: INVALIDATION. When data changes, the cache must be
cleared/updated, or users see stale data. Strategies: TTL (accept brief staleness),
explicit deletion on writes (cache.del), or cache tags.
Caching بیک اینڈ applications کے لیے highest-impact کی کارکردگی میں بہتری میں سے ایک ہے، اور NestJS کا بلٹ ان caching module اسے صاف ستھرا اور مطابقت پذیر بناتا ہے۔
یہ سمجھنا اہم ہے کیونکہ read-heavy APIs بہت زیادہ فائدہ اٹھاتے ہیں مہنگے operations کو cache کرنے سے (database queries، external API calls، computations) — latency اور load میں نمایاں کمی۔
NestJS سادہ auto-caching دونوں فراہم کرتا ہے (GET endpoints کے لیے CacheInterceptor) اور fine-grained manual control (CACHE_MANAGER get-or-fetch pattern مخصوص operations کے لیے)۔
اہم بات یہ ہے کہ unified API مختلف stores کے ساتھ کام کرتا ہے، تو وہی code in-memory caching (تیز، single-instance) یا Redis (متعدد instances میں shared cache) استعمال کر سکتا ہے — اور یہ جاننا کہ in-memory cache shared نہیں ہے جب horizontally scale کریں (distributed caching کے لیے Redis درکار) ایک اہم architectural نقطہ ہے۔
براہ راست اہم یہ ہے کہ caching کی مرکزی مشکل کو سمجھنا — invalidation (cache کو صاف کرنا یا اپڈیٹ کرنا جب ڈیٹا بدلے، TTL یا explicit deletion کے ذریعے، stale ڈیٹا سے بچنے کے لیے) — کیونکہ یہ غلط کرنا classic caching ناکامی ہے۔
یہ جاننا کہ کب اور کہاں caching لاگو کریں، deployment کے لیے صحیح store منتخب کریں، اور invalidation کو صحیح طریقے سے سنبھالیں تیز اور scalable NestJS services بنانے کے لیے قیمتی senior-level knowledge ہے۔
تفصیلی جوابات کے ساتھ IT انٹرویو سوالات کی ایک لائبریری — جونیئر سے سینئر تک۔
عطیہ دیں