NestJS एक built-in caching module (@nestjs/cache-manager) प्रदान गर्छ जसमा एकीकृत API छ जो विभिन्न stores मा काम गर्छ — डिफल्टरूपमा in-memory, वा multiple instances मा distributed caching को लागि Redis। 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 प्रतिक्रियाहरू cache गर्छ (URL द्वारा keyed) र दोहोरिएको request मा 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 गर्दा पूर्ण नियन्त्रण मिल्छ — get-or-fetch pattern (cache जाँच गर्नुहोस्, स्रोतमा फर्किनुहोस्, परिणाम सङ्ग्रह गर्नुहोस्) विशिष्ट महँगो operations cache गर्न को लागि।
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
यही API, Redis द्वारा समर्थित, सबै app instances मा साझा cache दिन्छ — एकै पल multiple instances चलाउँदा आवश्यक (एक in-memory cache तिनीहरू बीचमा साझा गरिदैन)।
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 back-end applications को लागि उच्चतम-प्रभाव कार्यप्रदर्शन अनुकूलनहरू मध्ये एक हो, र NestJS को built-in caching module यसलाई स्वच्छ र सङ्गत बनाउछ।
यो समझ्न महत्त्वपूर्ण छ किनभने read-heavy APIs महँगो operations (database queries, बाहिरी API calls, computations) cache गरेर असाधारण लाभ पान्छन् — latency र load नाटकीय रूपमा घटाउँछन्।
NestJS दुवै सरल auto-caching (GET endpoints को लागि CacheInterceptor) र fine-grained manual नियन्त्रण (विशिष्ट operations को लागि CACHE_MANAGER get-or-fetch pattern) प्रदान गर्छ।
मुख्य रूपमा, एकीकृत API विभिन्न stores को साथ काम गर्छ, त्यसैले यही code ले in-memory caching (छिटो, single-instance) वा Redis (multiple instances मा साझा cache) प्रयोग गर्न सक्छ — र यह जान्नु कि एक in-memory cache साझा गरिदैन जब horizontally स्केल गर्दा (distributed caching को लागि Redis आवश्यक) एक महत्त्वपूर्ण architectural बिन्दु हो।
बराबरको महत्त्व हो caching को केन्द्रीय कठिनाई समझ्नु — invalidation (TTL वा स्पष्ट deletion को माध्यमबाट cache स्पष्ट गर्नु वा अपडेट गर्नु, stale data सेवा गर्न बचाउन) — किनभने यो गलत गर्न यो caching failure को क्लासिक हो।
कब र कसरी caching लागु गर्न, deployment को लागि सही store छनोट गर्न, र invalidation सही ढङ्गले सम्भालन गर्न थाहा पाउनु भनेको fast, scalable NestJS services निर्माण गर्नको लागि मूल्यवान senior-level ज्ञान हो।
विस्तृत उत्तरसहित IT अन्तर्वार्ता प्रश्नहरूको पुस्तकालय — जुनियरदेखि सिनियरसम्म।
दान गर्नुहोस्