NestJS fornisce un modulo caching integrato (@nestjs/cache-manager) con un'API unificata che funziona su diversi store — in-memory per impostazione predefinita, oppure Redis per il caching distribuito su più istanze. Il caching migliora drammaticamente le prestazioni evitando lavoro costoso ripetuto.
({
: [
.({
: ,
: ,
: ,
}),
],
})
{}
@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
}
}
Il CacheInterceptor memorizza automaticamente nella cache le risposte degli endpoint GET (indicizzate per URL) e serve i risultati in cache alle richieste successive — il modo più semplice per cachare endpoint con letture intensive.
@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;
}
}
L'iniezione di CACHE_MANAGER offre il controllo totale — il pattern get-or-fetch (controllare la cache, ricorrere alla fonte, memorizzare il risultato) per cachare operazioni specifiche costose.
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
La stessa API, supportata da Redis, fornisce una cache condivisa su tutte le istanze dell'app — essenziale quando si eseguono più istanze (una cache in-memory non è condivisa tra di esse).
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.
Il caching è una delle ottimizzazioni di performance a più alto impatto per le applicazioni back-end, e il modulo caching integrato di NestJS lo rende pulito e coerente. 'è importante capirlo perché le API con letture intensive traggono enormi benefici dal caching di operazioni costose (query di database, chiamate API esterne, calcoli) — riducendo drasticamente la latenza e il carico.
NestJS offre sia il caching automatico semplice (il CacheInterceptor per gli endpoint GET) che il controllo manuale fine (il pattern get-or-fetch di CACHE_MANAGER per operazioni specifiche).
Cruciale è che l'API unificata funziona con diversi store, quindi lo stesso codice può utilizzare il caching in-memory (veloce, a istanza singola) oppure Redis (una cache condivisa su più istanze) — e sapere che una cache in-memory non è condivisa durante il ridimensionamento orizzontale (richiedendo Redis per il caching distribuito) è un punto architetturale importante.
Ugualmente importante è comprendere la difficoltà centrale del caching — l'invalidazione (cancellare o aggiornare la cache quando i dati cambiano, tramite TTL o cancellazione esplicita, per evitare di servire dati stantii) — poiché sbagliare qui è il classico fallimento del caching.
Sapere come e quando applicare il caching, scegliere lo store giusto per il deployment, e gestire correttamente l'invalidazione è una preziosa conoscenza di livello senior per costruire servizi NestJS veloci e scalabili.