NestJS ofron një modul të integruar caching (@nestjs/cache-manager) me një API të unifikuar që funksionon në të gjitha depot — në memorie sipas parazgjedhjes, ose Redis për caching të shpërndarë në shumë instanca. Caching-u përmirëson në mënyrë drastike performancën duke shmangur punën e përsëritur të shtrenjtë.
({
: [
.({
: ,
: ,
: ,
}),
],
})
{}
@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 automatikisht cache-on përgjigjet e endpoint-eve GET (të çelësuar sipas URL-it) dhe shërben rezultate të cache-uar në kërkesa të përsëritura — mënyra më e thjeshtë për të cache-uar endpoint-et që lexojnë shumë.
@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;
}
}
Injektimi i CACHE_MANAGER jep kontroll të plotë — modeli get-or-fetch (verifikimi i cache-it, kthimi në burim, ruajtja e rezultatit) për caching-un e operacioneve specifike të shtrenjtë.
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
I njëjti API, i mbështetur nga Redis, jep një cache të përbashkuar në të gjitha instancat e aplikacionit — thelbësor kur shpërndahet aplikacioni në shumë instanca (një cache në memorie nuk ndahet midis tyre).
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-u është një nga optimizazimet më me ndikim të lartë për aplikacionet back-end, dhe moduli i integruar i caching-ut në NestJS e bën këtë të pastër dhe konsistent.
Në është e rëndësishme ta kuptojmë sepse API-et që lexojnë shumë përfitojnë jashtëzakonisht nga cache-imi i operacioneve të shtrenjtë (pyetjet në bazë të dhënash, thirrjet API të jashtme, llogaritjet) — duke zvogëluar ndjeshëm latencën dhe ngarkesën.
NestJS ofron tanto auto-caching të thjeshtë (CacheInterceptor për endpoint-et GET) sa dhe kontroll të imët manual (CACHE_MANAGER modeli get-or-fetch për operacione specifike).
Në mënyrë të rëndësishme, API-ja e unifikuar funksionon me depoja të ndryshme, kështu që i njëjti kod mund të përdorë caching në memorie (i shpejtë, një instancë) ose Redis (cache i përbashkuar në shumë instanca) — dhe të ditur se një cache në memorie nuk ndahet kur rritet horizontalisht (duke kërkuar Redis për caching të shpërndarë) është një pikë e rëndësishme arkitekturore.
Enjë aq i rëndësishëm është të kuptojmë vështirësinë qendrore të cache-it — invalidimi (pastrimi ose përditësimi i cache-it kur të dhënat ndryshojnë, përmes TTL ose fshirjes së qartë, për të shmangur shërbimin e të dhënave të vjetra) — sepse bërja e kësaj gabim është dështim klasik i caching-ut.
Të diturit se si dhe kur të zbatohet caching-u, zgjedhja e depos të duhur për ndërtimin, dhe trajtimi i saktë i invalidimit është njohuri e vlefshme në nivelin e këshilltarit për ndërtimin e shërbimeve NestJS të shpejtë dhe të shkallëzueshme.