A NestJS egy beépített gyorsítótárazási modult (@nestjs/cache-manager) biztosít, amely egységes API-val működik a tárolók között — alapértelmezésben memóriabeli, vagy Redis az elosztott gyorsítótárazáshoz több példány között. A gyorsítótárazás drámailag javítja a teljesítményt azáltal, hogy elkerüli az ismételt költséges műveletek végrehajtását.
({
: [
.({
: ,
: ,
: ,
}),
],
})
{}
@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
}
}
A CacheInterceptor automatikusan gyorsítótárazza a GET végpont válaszait (URL-vel indexelve) és ismételt kérésekkor a gyorsítótárazott eredményeket szolgáltatja — a legegyszerűbb módszer az olvasásintenzív végpontok gyorsítótárazására.
@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;
}
}
A CACHE_MANAGER injektálása teljes kontrollt ad — a get-or-fetch minta (gyorsítótár ellenőrzése, visszatérés a forráshoz, eredmény tárolása) specifikus költséges műveletek gyorsítótárazásához.
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
Az ugyanaz az API, Redis háttérrel, egy megosztott gyorsítótárat ad az összes alkalmazás-példány között — lényeges, ha több példányt futtat (egy memóriabeli gyorsítótár nem megosztott az alkalmazás-példányok között).
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.
A gyorsítótárazás az egyik legmagasabb hatású teljesítménnyel kapcsolatos optimalizálás a backend alkalmazások számára, és a NestJS beépített gyorsítótárazási modulja tiszta és konzisztens.
Fontos megérteni, mert az olvasásintenzív API-k óriási mértékben profitálnak a költséges műveletek gyorsítótárazásából (adatbázis-lekérdezések, külső API-hívások, számítások) — drámailag csökkentve a késleltetést és a terhelést.
A NestJS mind az egyszerű automatikus gyorsítótárazást (a CacheInterceptor GET végpontokhoz) mind a finomított manuális kontrollt (a CACHE_MANAGER get-or-fetch minta specifikus műveletek számára) kínálja.
Döntő fontosságú, hogy az egységes API különböző tárolókkal működik, így az ugyanaz a kód használhat memóriabeli gyorsítótárazást (gyors, egypéldányos) vagy Redis-t (megosztott gyorsítótár több példány között) — és annak ismerete, hogy egy memóriabeli gyorsítótár nem megosztott vízszintes skálázáskor (Redis szükséges az elosztott gyorsítótárazáshoz) egy fontos építészeti pont.
Egyenlően fontos a gyorsítótárazás központi nehézsége — az invalidálás megértése (a gyorsítótár törlése vagy frissítése, amikor az adatok megváltoznak, TTL vagy explicit törlés által, az elavult adatok visszaszolgáltatásának elkerülésére) — mivel ennek rossz kezelése a klasszikus gyorsítótárazási kudarc.
Az ismerete arról, hogy hogyan és mikor alkalmazzunk gyorsítótárazást, a megfelelő tárolót válasszuk a telepítéshez, és az invalidálást helyesen kezeljük, értékes senior szintű ismeret a gyors, skálázható NestJS szolgáltatások építéséhez.