NestJS poskytuje vestavěný caching modul (@nestjs/cache-manager) s jednotným API, které funguje across stores — in-memory ve výchozím nastavení, nebo Redis pro distribuovaný caching across multiple instances. Caching dramaticky zlepšuje výkon tím, že se vyhýbá opakované drahé práci.
({
: [
.({
: ,
: ,
: ,
}),
],
})
{}
@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 automaticky cachuje odpovědi GET endpointů (s klíčem podle URL) a vrací cachované výsledky na opakované requesty — nejjednoduší způsob, jak cachovat read-heavy endpointy.
@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;
}
}
Injektování CACHE_MANAGER dává plnou kontrolu — get-or-fetch pattern (kontrola cache, fallback na zdroj, uložení výsledku) pro caching specifických drahých operací.
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
Též API, podporované Redis, dává sdílený cache across všechny app instance — essential když se spouští více instancí (in-memory cache není sdílen mezi nimi).
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 z nejvyšších-impact performance optimizací pro back-end aplikace, a vestavěný caching modul NestJS to dělá čistě a konzistentně.
Porozumění je důležité, protože read-heavy API obsáhle benefitují z cachování drahých operací (database queries, external API calls, computations) — dramaticky snižují latenci a zátěž.
NestJS nabízí jak jednoduché auto-caching (CacheInterceptor pro GET endpointy) tak fine-grained manuální kontrolu (CACHE_MANAGER get-or-fetch pattern pro specifické operace).
Kriticky důležité je, že jednotné API funguje s různými stores, takže stejný kód může používat in-memory caching (rychlý, single-instance) nebo Redis (sdílený cache across multiple instance) — a vědět, že in-memory cache není sdílen při horizontálním škálování (vyžadující Redis pro distribuovaný caching) je důležitý architektonický bod.
Rovněž důležité je pochopit centrální obtíž cachingu — invalidaci (clearing nebo updating cache když se data změní, via TTL nebo explicit deletion, aby se zabránilo servírování stale data) — protože špatně to provést je klasická caching chyba.
Vědět jak a kdy caching aplikovat, zvolit správný store pro deployment, a správně handleovat invalidaci je cenné senior-level znalosti pro budování rychlých, scalable NestJS services.