NestJS biedt een ingebouwde caching module (@nestjs/cache-manager) met een uniforme API die werkt met verschillende stores — standaard in-memory, of Redis voor gedistribueerde caching over meerdere instanties. Caching verbetert de prestaties dramatisch door herhaald duur werk te voorkomen.
({
: [
.({
: ,
: ,
: ,
}),
],
})
{}
@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
}
}
De CacheInterceptor cached automatisch antwoorden van GET endpoints (gecodeerd op basis van URL) en served cached resultaten bij herhaalde requests — de eenvoudigste manier om endpoints met veel leesbewerkingen te cachen.
@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;
}
}
Door CACHE_MANAGER in te injecteren krijg je volledige controle — het get-or-fetch patroon (check cache, fall back naar bron, sla resultaat op) voor het cachen van specifieke dure operaties.
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
Dezelfde API, ondersteund door Redis, geeft een gedeelde cache over alle app-instanties — essentieel wanneer je meerdere instanties uitvoert (een in-memory cache wordt niet gedeeld tussen instanties).
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 is een van de impact-rijkste prestatieoptimalisaties voor backend-applicaties, en NestJS's ingebouwde caching module maakt dit schoon en consistent.
Het begrijpen ervan is belangrijk omdat read-heavy APIs enorm baat hebben bij het cachen van dure operaties (databasequery's, externe API-aanroepen, berekeningen) — waardoor latentie en belasting dramatisch afnemen.
NestJS biedt zowel eenvoudig auto-caching (de CacheInterceptor voor GET endpoints) als nauwkeurige handmatige controle (het CACHE_MANAGER get-or-fetch patroon voor specifieke operaties).
Cruciaal is dat de uniforme API werkt met verschillende stores, dus dezelfde code kan in-memory caching (snel, single-instance) of Redis (een gedeelde cache over meerdere instanties) gebruiken — en het beseffen dat een in-memory cache niet gedeeld wordt bij horizontale schaling (Redis vereist voor gedistribueerde caching) is een belangrijk architecturaal punt.
Evenals belangrijk is het begrijpen van het centrale probleem van caching — invalidatie (het leegmaken of bijwerken van de cache wanneer data verandert, via TTL of expliciete verwijdering, om het serveren van verouderde data te voorkomen) — want dit verkeerd doen is de klassieke caché-fout.
Weten hoe en wanneer je caching moet toepassen, de juiste store voor de implementatie kiezen en invalidatie correct afhandelen is waardevol senior-level kennis voor het bouwen van snelle, schaalbare NestJS-services.