NestJS tilbyder et indbygget caching-modul (@nestjs/cache-manager) med et unified API, som fungerer på tværs af forskellige stores — in-memory som standard, eller Redis til distribueret caching på tværs af flere instanser. Caching forbedrer ydeevnen dramatisk ved at undgå gentagne dyre operationer.
({
: [
.({
: ,
: ,
: ,
}),
],
})
{}
@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 cacher automatisk svar fra GET-endpoints (nøglet efter URL) og serverer cachede resultater ved gentagne anmodninger — den simpleste måde at cache læse-intensive endpoints.
@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;
}
}
Injicering af CACHE_MANAGER giver fuld kontrol — get-or-fetch-mønsteret (check cache, fallback til kilde, gem resultat) til caching af specifikke dyre operationer.
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
Samme API, understøttet af Redis, giver et delt cache på tværs af alle app-instanser — essentielt når der køres flere instanser (et in-memory cache deles ikke mellem dem).
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 er en af de højest virkende ydelses-optimeringer for back-end-applikationer, og NestJS's indbyggede caching-modul gør det rent og konsistent.
Det er vigtigt at forstå, fordi læse-intensive API'er har enormt gavn af caching af dyre operationer (databaseforespørgsler, eksterne API-kald, beregninger) — hvilket dramatisk reducerer latenstid og belastning.
NestJS tilbyder både simpel auto-caching (CacheInterceptor til GET-endpoints) og finkornet manuel kontrol (CACHE_MANAGER get-or-fetch-mønsteret til specifikke operationer).
Krucielt er det unified API kompatibelt med forskellige stores, så samme kode kan bruge in-memory caching (hurtigt, enkelt-instans) eller Redis (et delt cache på tværs af flere instanser) — og at vide, at et in-memory cache ikke deles ved horizontal skalering (kræver Redis til distribueret caching) er et vigtigt arkitektur-punkt.
Ligeledes vigtig er forståelsen af cachings centrale vanskelighed — invalidering (rydding eller opdatering af cache når data ændres, via TTL eller eksplicit sletning, for at undgå at servere forældede data) — da det at få dette forkert er den klassiske cache-fejl.
At vide, hvordan og hvornår man anvender caching, vælger den rigtige store til implementeringen, og håndterer invalidering korrekt, er værdifuld senior-niveau viden til at bygge hurtige, skalerbare NestJS-services.