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