NestJS tillhandahåller en inbyggd caching-modul (@nestjs/cache-manager) med ett enhetligt API som fungerar över olika lagringstyper — in-memory som standard, eller Redis för distribuerad caching över flera instanser. Caching förbättrar prestandan dramatiskt genom att undvika upprepad dyrt arbete.
({
: [
.({
: ,
: ,
: ,
}),
],
})
{}
@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 cachelagrar automatiskt GET endpoint-svar (indexerade efter URL) och serverar cachade resultat vid upprepade förfrågningar — det enklaste sättet att cachelagra läsintensiva 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;
}
}
Att injicera CACHE_MANAGER ger full kontroll — get-or-fetch-mönstret (kontrollera cache, återgå till källa, lagra resultat) för caching av specifika dyra operationer.
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
Samma API, stödd av Redis, ger en delad cache över alla app-instanser — väsentlig när man kör flera instanser (en in-memory cache delas inte mellan 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 är en av de högst effektiva prestandaoptimeringar för backend-applikationer, och NestJS:s inbyggda caching-modul gör det rent och konsekvent.
Det är viktigt att förstå eftersom läsintensiva API:er gynnas enormt av caching av dyra operationer (databasfrågor, externa API-anrop, beräkningar) — vilket dramatiskt minskar latens och belastning.
NestJS erbjuder både enkel auto-caching (CacheInterceptor för GET endpoints) och finkörnig manuell kontroll (CACHE_MANAGER get-or-fetch-mönstret för specifika operationer).
Avgörande är att det enhetliga API:et fungerar med olika lagringstyper, så samma kod kan använda in-memory caching (snabb, enkel instans) eller Redis (en delad cache över flera instanser) — och att veta att en in-memory cache inte delas vid horisontell skalning (vilket kräver Redis för distribuerad caching) är en viktig arkitektonisk poäng.
Lika viktigt är att förstå cachings centrala svårighet — invalidering (tömning eller uppdatering av cachen när data ändras, via TTL eller explicit borttagning, för att undvika att servera föråldrad data) — eftersom att få detta fel är det klassiska caching-misslyckandet.
Att veta hur och när man tillämpar caching, välja rätt lagringstyp för distributionen, och hantera invalidering korrekt är värdeful senior-level-kunskap för att bygga snabba, skalbara NestJS-tjänster.