NestJS menyediakan modul caching bawaan (@nestjs/cache-manager) dengan API yang seragam yang bekerja di berbagai penyimpanan — in-memory secara default, atau Redis untuk caching terdistribusi di berbagai instance. Caching secara dramatis meningkatkan performa dengan menghindari pekerjaan 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 otomatis meng-cache respons endpoint GET (dengan kunci berdasarkan URL) dan menyajikan hasil yang di-cache pada permintaan berulang — cara paling sederhana untuk meng-cache endpoint dengan beban baca tinggi.
@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;
}
}
Meng-inject CACHE_MANAGER memberikan kontrol penuh — pola get-or-fetch (periksa cache, jatuh kembali ke sumber, simpan hasil) untuk meng-cache 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, didukung oleh Redis, memberikan cache yang dibagikan di semua instance aplikasi — penting saat menjalankan multiple instance (cache in-memory tidak dibagikan di 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 adalah salah satu optimisasi performa dengan dampak tertinggi untuk aplikasi back-end, dan modul caching bawaan NestJS membuatnya bersih dan konsisten.
Memahaminya penting karena API dengan beban baca tinggi mendapat manfaat luar biasa dari caching operasi mahal (query database, panggilan API eksternal, komputasi) — secara dramatis mengurangi latensi dan beban.
NestJS menawarkan baik auto-caching sederhana (CacheInterceptor untuk endpoint GET) maupun kontrol manual yang presisi (pola get-or-fetch CACHE_MANAGER untuk operasi tertentu).
Yang penting, API yang seragam bekerja dengan penyimpanan berbeda, jadi kode yang sama dapat menggunakan caching in-memory (cepat, single-instance) atau Redis (cache bersama di berbagai instance) — dan mengetahui bahwa cache in-memory tidak dibagikan saat scaling horizontal (memerlukan Redis untuk caching terdistribusi) adalah poin arsitektur penting.
Sama pentingnya adalah memahami kesulitan pusat caching — invalidation (menghapus atau memperbarui cache saat data berubah, melalui TTL atau penghapusan eksplisit, untuk menghindari penyajian data usang) — karena melakukan ini dengan salah adalah kegagalan caching klasik.
Mengetahui bagaimana dan kapan menerapkan caching, memilih penyimpanan yang tepat untuk deployment, dan menangani invalidation dengan benar adalah pengetahuan level senior yang berharga untuk membangun layanan NestJS yang cepat dan dapat diskalakan.