NestJS suteikia integruotą cache-avimo modulį (@nestjs/cache-manager) su vieningu API, kuris veikia su skirtingomis saugyklomis — numatytas greitosios atminties, arba Redis dėl paskirstyto cache-avimo keliose instancijose. Cache-avimas dramatiškai pagerina našumą išvengiant pakartotinio brangiojo darbo.
({
: [
.({
: ,
: ,
: ,
}),
],
})
{}
@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 automatiškai cache-uoja GET galinio taško atsakymus (raktais pagal URL) ir pateikia cache-uotus rezultatus pakartotiniams užklausoms — paprasčiausias būdas cache-inti skaitymui sunkius galutinėms taškams.
@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;
}
}
Injekcija CACHE_MANAGER suteikia pilną kontrolę — get-or-fetch modelis (patikrinti cache-ą, grįžti prie šaltinio, saugoti rezultatą) cache-avimui tam tikrų brangių operacijų.
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
Tas pats API, palaikomas Redis, suteikia bendrą cache-ą visuose programos instancijose — būtina paleisti kelias instancijas (greitosios atminties cache-as nėra dalijamas tarp jų).
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-avimas yra viena iš didiausio poveikio našumo optimizacijų galinėms programoms, o NestJS integruotas cache-avimo modulis tai daro švariai ir nuosekliai.
Suprasti tai svarbu, nes skaitymui sunkios API labai naudojasi cache-avus brangias operacijas (duomenų bazės užklausas, išorinių API iškvietimus, skaičiavimus) — dramatiškai sumažindami latentiškumą ir apkrovą.
NestJS suteikia ir paprastą auto-cache-avimą (CacheInterceptor skirtas GET galutiniams taškams) ir smulkią rankinę kontrolę (CACHE_MANAGER get-or-fetch modelis tam tikroms operacijoms).
Krucialiai, vienodas API veikia su skirtingomis saugyklomis, todėl tas pats kodas gali naudoti greitosios atminties cache-avimą (greitą, vienos instancijos) arba Redis (bendrą cache-ą keliose instancijose) — ir žinojimas, kad greitosios atminties cache-as nėra dalijamas kai skalėjama horizontaliai (reikalingas Redis paskirstytam cache-avimui) yra svarbus architektūrinis dalykas.
Ekval svarbu yra suprasti cache-avimo centrinį sunkumą — invalidacją (cache-o nutrynimą arba atnaujinimą keičiant duomenis, per TTL arba aiškų šalinimą, kad išvengtumėte pasenusių duomenų) — nes tai neteisingai padaryti yra klasikinis cache-avimo gedimas.
Žinojimas kaip ir kada taikyti cache-avimą, pasirinkti tinkamą saugyklą diegimui ir teisingai tvarkytis su invalidacija yra vertinga aukštesnio lygio žinių dėl greitų ir masteliojamų NestJS paslaugų kūrimo.