NestJS oferă un modul de cache încorporat (@nestjs/cache-manager) cu un API unificat care funcționează pe diferite tipuri de stocare — în memorie implicit, sau Redis pentru cache distribuit pe mai multe instanțe. Cache-ul îmbunătățește dramatic performanța evitând repetarea muncii costisitoare.
({
: [
.({
: ,
: ,
: ,
}),
],
})
{}
@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 pune automat în cache răspunsurile endpoint-urilor GET (cheia fiind URL-ul) și servește rezultatele cache-ate la cererile repetate — cel mai simplu mod de a pune în cache endpoint-uri cu trafic intens de citire.
@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;
}
}
Injectarea CACHE_MANAGER oferă control total — modelul get-or-fetch (verifi cache, cazi înapoi la sursă, stochezi rezultatul) pentru cache-ul operațiilor specifice costisitoare.
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
Același API, susținut de Redis, oferă un cache partajat pe toate instanțele aplicației — esențial când rulezi mai multe instanțe (un cache în memorie nu este partajat între ele).
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.
Cache-ul este una dintre optimizările de performanță cu cel mai mare impact pentru aplicațiile back-end, și modulul de cache încorporat al NestJS o face curată și consistentă.
Înțelegerea sa este importantă deoarece API-urile cu trafic intens de citire beneficiază enorm de cache-ul operațiilor costisitoare (interogări de bază de date, apeluri la API-uri externe, calcule) — reducând dramatic latența și încărcarea.
NestJS oferă atât cache automat simplu (CacheInterceptor pentru endpoint-uri GET) cât și control fin-granular manual (modelul CACHE_MANAGER get-or-fetch pentru operații specifice).
Crucial este faptul că API-ul unificat funcționează cu diferite tipuri de stocare, deci același cod poate folosi cache în memorie (rapid, pentru o singură instanță) sau Redis (un cache partajat pe mai multe instanțe) — și știind că un cache în memorie nu este partajat la scalarea orizontală (necesitând Redis pentru cache distribuit) este un punct arhitectural important.
La fel de important este înțelegerea dificultății centrale a cache-ului — invalidarea (ștergerea sau actualizarea cache-ului când datele se schimbă, prin TTL sau ștergere explicită, pentru a evita servirea datelor vechi) — deoarece greșirea aceasta este eșecul clasic al cache-ului.
Cunoașterea cum și când să aplici cache, alegerea tipului potrivit de stocare pentru implementare, și gestionarea corectă a invalidării este cunoștință valoroasă la nivel senior pentru construirea serviciilor NestJS rapide și scalabile.