NestJS menyediakan modul caching terbina dalam (@nestjs/cache-manager) dengan API bersatu yang berfungsi merentas pelbagai store — dalam memori secara lalai, atau Redis untuk caching teragih merentas berbilang instance. Caching meningkatkan prestasi secara mendadak dengan mengelakkan kerja mahal yang berulang.
({
: [
.({
: ,
: ,
: ,
}),
],
})
{}
@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 secara automatik melakukan caching terhadap respons endpoint GET (dikunci mengikut URL) dan menyajikan hasil yang di-cache pada permintaan berulang — cara paling mudah untuk melakukan caching pada endpoint yang banyak operasi baca.
@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;
}
}
Menyuntik CACHE_MANAGER memberikan kawalan penuh — corak get-or-fetch (semak cache, kembali ke sumber, simpan hasil) untuk melakukan caching terhadap operasi mahal tertentu.
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
API yang sama, disokong oleh Redis, memberikan cache dikongsi merentas semua instance aplikasi — penting apabila menjalankan berbilang instance (cache dalam memori tidak dikongsi antara mereka).
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 ialah salah satu pengoptimuman prestasi berkesan tertinggi untuk aplikasi back-end, dan modul caching terbina dalam NestJS menjadikannya kemas dan konsisten.
Memahaminya penting kerana API yang banyak operasi baca mendapat manfaat besar daripada caching operasi mahal (pertanyaan pangkalan data, panggilan API luaran, pengiraan) — mengurangkan latency dan beban secara mendadak.
NestJS menawarkan kedua-dua auto-caching mudah (CacheInterceptor untuk endpoint GET) dan kawalan manual berbutir halus (corak get-or-fetch CACHE_MANAGER untuk operasi tertentu).
Yang penting, API bersatu ini berfungsi dengan store yang berbeza, jadi kod yang sama boleh menggunakan caching dalam memori (laju, satu instance) atau Redis (cache dikongsi merentas berbilang instance) — dan mengetahui bahawa cache dalam memori tidak dikongsi apabila menskala secara mendatar (memerlukan Redis untuk caching teragih) ialah satu titik seni bina yang penting.
Sama pentingnya ialah memahami kesukaran utama caching — invalidasi (membersihkan atau mengemas kini cache apabila data berubah, melalui TTL atau pemadaman eksplisit, untuk mengelakkan menyajikan data lapuk) — kerana melakukan ini secara salah ialah kegagalan caching klasik.
Mengetahui cara dan bila untuk menerapkan caching, memilih store yang tepat untuk deployment, dan mengendalikan invalidasi dengan betul ialah pengetahuan peringkat senior yang berharga untuk membina servis NestJS yang laju dan boleh diskalakan.