तुम NestJS मध्ये कॅशिंग कसे जोडता?

Question

Accepted Answer

NestJS एक अंतर्निर्मित **कॅशिंग मॉड्यूल** (`@nestjs/cache-manager`) प्रदान करते ज्याचा एक एकीकृत API विविध स्टोरस् मध्ये काम करतो — डिफॉल्टनुसार मेमरी-मध्ये, किंवा अनेक उदाहरणांमध्ये वितरित कॅशिंगसाठी **Redis**। कॅशिंग पुन्हा-पुन्हा होणाऱ्या महाग कामास टाळून कार्यप्रदर्शन नाटकीयरित्या सुधारते.

## कॅश मॉड्यूल सेटअप करणे

```ts
@Module({
  imports: [
    CacheModule.register({
      ttl: 60000,        // default time-to-live (ms) — entries expire after 60s
      max: 100,          // max items in memory (in-memory store)
      isGlobal: true,    // available app-wide
    }),
  ],
})
export class AppModule {}
```

## इंटरसेप्टरसह ऑटो-कॅशिंग एंडपॉइंट्स

```ts
@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
  }
}
```

The `CacheInterceptor` automatically caches `GET` endpoint responses (keyed by URL) and serves cached results on repeat requests — the simplest way to cache read-heavy endpoints.

## CacheManager सह मॅन्युअल कॅशिंग (अधिक नियंत्रण)

```ts
@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;
  }
}
```

Injecting `CACHE_MANAGER` gives full control — the get-or-fetch pattern (check cache, fall back to source, store result) for caching specific expensive operations.

## Redis सह वितरित कॅशिंग (अनेक उदाहरणे)

```ts
CacheModule.registerAsync({
  useFactory: async () => ({
    store: await redisStore({ url: process.env.REDIS_URL }),   // use Redis as the store
    ttl: 60000,
  }),
});
```

The same API, backed by **Redis**, gives a **shared** cache across all app instances — essential when running multiple instances (an in-memory cache isn't shared between them).

## कठीण भाग: कॅश अमान्यकरण

```ts
async updateProduct(id: string, data) {
  await this.db.update(id, data);
  await this.cache.del(`product:${id}`);   // INVALIDATE on change → avoid stale data
}
```

```text
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.
```

## ते महत्वाचे का आहे

कॅशिंग बैक-एंड ऍप्लिकेशन्ससाठी सर्वोच्च-प्रभाव कार्यप्रदर्शन ऑप्टिमाइজेशन्सपैकी एक आहे, आणि NestJS चा अंतर्निर्मित कॅशिंग मॉड्यूल हे स्वच्छ आणि सुसंगत करते.

हे समजून घेणे महत्वाचे आहे कारण read-heavy APIs महाग ऑपरेशन्स (डेटाबेस क्वेरीज, बाह्य API कॉलस्, गणनाएं) कॅशिंगमधून विशाल लाभ मिळवतात — latency आणि load नाटकीयरित्या कमी करते.

NestJS साधे ऑटो-कॅशिंग (GET एंडपॉइंट्ससाठी `CacheInterceptor`) आणि बारीक मॅन्युअल नियंत्रण (विशिष्ट ऑपरेशन्ससाठी `CACHE_MANAGER` get-or-fetch pattern) दोन्ही ऑफर करते.

महत्त्वपूर्ण म्हणजे, एकीकृत API विविध स्टोरस् सह काम करतो, त्यामुळे समान कोड **in-memory कॅशिंग** (जलद, एकल-उदाहरण) किंवा **Redis** (अनेक उदाहरणांमध्ये सामायिक कॅश) वापरू शकतो — आणि in-memory कॅश क्षैतिजरित्या स्केल करताना सामायिक नाही हे जाणून घेणे (वितरित कॅशिंगसाठी Redis आवश्यक) एक महत्वाचा आर्किटेक्चरल बिंदू आहे.

सारखेच महत्वाचे म्हणजे कॅशिंगच्या मध्यवर्ती अडचणीचे समजून घेणे — **अमान्यकरण** (कॅश साफ करणे किंवा अपडेट करणे जेव्हा डेटा बदलतो, TTL किंवा स्पष्ट deletion द्वारे, stale डेटा सेवा देणे टाळण्यासाठी) — कारण हे चुकीचे करणे हे classical कॅशिंग अपयशाचे कारण आहे.

कॅशिंग कसे आणि केव्हा लागू करायचे हे जाणून घेणे, deployment साठी योग्य स्टोर निवडणे, आणि अमान्यकरण योग्यरित्या हाताळणे हे वेगवान, scalable NestJS services बांधण्यासाठी मूल्यवान senior-level ज्ञान आहे.