NestJS ஒரு உள்ளமைந்த caching module-ஐ (@nestjs/cache-manager) ஒரு ஒருங்கிணைந்த API உடன் வழங்குகிறது, இது stores முழுவதும் வேலை செய்கிறது — இயல்பாக in-memory, அல்லது பல 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 responses-ஐ தானாகவே cache செய்கிறது (URL மூலம் keyed) மற்றும் மீண்டும் வரும் requests-இல் cached results-ஐ வழங்குகிறது — 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-ஐ சரிபார்க்கவும், source-க்கு fall back ஆகவும், result-ஐ store செய்யவும்).
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
அதே API, Redis மூலம் backed ஆனது, அனைத்து 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.
Back-end applications-க்கான மிக அதிக-தாக்கம் கொண்ட செயல்திறன் optimizations-இல் caching ஒன்றாகும், மேலும் NestJS-இன் உள்ளமைந்த caching module அதை சுத்தமாகவும் நிலையாகவும் ஆக்குகிறது.
அதைப் புரிந்துகொள்வது முக்கியம், ஏனெனில் read-heavy APIs விலையுயர்ந்த operations-ஐ (database queries, external API calls, computations) cache செய்வதன் மூலம் மிகப்பெரிய பயனைப் பெறுகின்றன — latency மற்றும் load-ஐ வியத்தகு முறையில் குறைக்கின்றன.
NestJS எளிய auto-caching (GET endpoints-க்கான CacheInterceptor) மற்றும் fine-grained manual control (குறிப்பிட்ட 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 தேவை) ஒரு முக்கியமான கட்டிடக்கலை புள்ளியாகும்.
Caching-இன் மைய சிரமம் — invalidation (stale data-ஐ வழங்குவதைத் தவிர்க்க, data மாறும்போது cache-ஐ அழித்தல் அல்லது update செய்தல், TTL அல்லது explicit deletion மூலம்) — ஐ புரிந்துகொள்வதும் சமமாக முக்கியம், ஏனெனில் இதைத் தவறாகச் செய்வது classic caching தோல்வியாகும்.
Caching-ஐ எப்படி, எப்போது பயன்படுத்துவது, deployment-க்கான சரியான store-ஐ தேர்வுசெய்வது, மற்றும் invalidation-ஐ சரியாகக் கையாள்வது ஆகியவை வேகமான, scalable NestJS services-ஐ உருவாக்குவதற்கான மதிப்புமிக்க senior-level அறிவாகும்.