NestJS pruža ugrađeni caching modul (@nestjs/cache-manager) s jedinstvenim API-jem koji radi sa svim storage-ima — u memoriji prema zadanoj postavci, ili Redis za distribuirani caching preko više instanci. Caching dramatično poboljšava performanse izbjegavanjem ponovljenog skupog rada.
({
: [
.({
: ,
: ,
: ,
}),
],
})
{}
@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 automatski cachira GET endpoint odgovore (key je URL) i koristi cachiranu rezultate na ponovljenim zahtjevima — najjednostavniji način za caching read-heavy endpointa.
@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;
}
}
Ubacivanje CACHE_MANAGER daje punu kontrolu — get-or-fetch pattern (provjeri cache, padni natrag na izvor, spremi rezultat) za caching specifičnih skupih operacija.
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
Isti API, podržan s Redis-om, daje zajedničku cache preko svih app instanci — esencijalno kad se izvršava više instanci (u-memoriji cache nije dijeljeno između njih).
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 je jedna od najprimjenjivijih optimizacija performansi za back-end aplikacije, a NestJS-ov ugrađeni caching modul čini to čisto i konzistentno.
Je li važno razumjeti jer read-heavy API-ji enormno koriste od cachiranja skupih operacija (database upiti, vanjski API pozivi, izračuni) — dramatično smanjujući latenciju i opterećenje.
NestJS nudi i jednostavno auto-caching (CacheInterceptor za GET endpointe) i finogranu ručnu kontrolu (CACHE_MANAGER get-or-fetch pattern za specifične operacije).
Krucijalno je da je jedinstveni API kompatibilan s različitim storage-ima, tako da isti kod može koristiti u-memoriji caching (brz, single-instance) ili Redis (zajednička cache preko više instanci) — i znati da u-memoriji cache nije dijeljeno pri skaliranju horizontalno (što zahtijeva Redis za distribuirani caching) je važna arhitekturna točka.
Jednako važno je razumjeti centralnu težinu cachinga — invalidacija (brisanje ili ažuriranje cache-a kad se podaci promijene, putem TTL-a ili eksplicitnog brisanja, da se izbjegne posluživanje zastarjelih podataka) — jer greška u ovome je klasični caching neuspjeh.
Znati kako i kada primijeniti caching, odabrati pravi storage za deployment, i pravilno rukovati invalidacijom je vrijedna senior-level znanja za gradnju brze, skalabilne NestJS usluge.