NestJS tarjoaa sisäänrakennetun välimuistimoduulin (@nestjs/cache-manager), jossa on yhtenäinen API, joka toimii eri välimuistien kanssa — oletuksena muistissa, tai Redis jaetun välimuistin käyttöä varten useiden instanssien välillä. Välimuistiin tallennus parantaa suorituskykyä dramaattisesti välttämällä toistuvia kalliita operaatioita.
({
: [
.({
: ,
: ,
: ,
}),
],
})
{}
@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 tallentaa automaattisesti GET-päätepisteen vastaukset välimuistiin (avaimena URL) ja tarjoilee välimuistissa olevia tuloksia toistuvissa pyynnöissä — yksinkertaisin tapa välimuistiin tallentaa lukuintensiivisiä päätepisteita.
@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;
}
}
CACHE_MANAGER-injektio antaa täyden hallinnan — get-or-fetch-malli (tarkista välimuisti, palaa alkuperäiseen lähteeseen, tallenna tulos) spesifisten kalliiden operaatioiden välimuistiin tallenukseen.
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
Sama API, jonka takana on Redis, tarjoaa jaetun välimuistin kaikilla sovelluksen instansseilla — välttämätöntä useiden instanssien ajamisen yhteydessä (muistissa oleva välimuisti ei ole jaettu niiden välillä).
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.
Välimuistiin tallennus on yksi suurimman vaikutuksen omaavista suorituskyvyn optimoinneista taustajärjestelmäsovelluksille, ja NestJS:n sisäänrakennettu välimuistimoduuli tekee siitä puhtaan ja yhtenäisen.
Ymmärtäminen on tärkeää, koska lukuintensiiviset API:t hyötyvät valtavasti kalliiden operaatioiden (tietokannan kyselyt, ulkoiset API-kutsut, laskutoimitukset) välimuistiin tallentamisesta — mikä vähentää viiveaikaa ja kuormaa dramaattisesti.
NestJS tarjoaa sekä yksinkertaisen automaattisen välimuistiin tallentamisen (CacheInterceptor GET-päätepisteille) että hienostuneita manuaalisia hallintakeinoja (CACHE_MANAGER get-or-fetch-mallia spesifisille operaatioille).
Ratkaisevasti, yhtenäinen API toimii eri välimuistin kanssa, joten sama koodi voi käyttää muistissa olevaa välimuistia (nopea, yksi instanssi) tai Redisiä (jaettu välimuisti useiden instanssien välillä) — ja se, että muistissa oleva välimuisti ei ole jaettu horisontaalisen skaalauksen yhteydessä (vaatii Redisiä jaetun välimuistiin tallennuksen kannalta), on tärkeä arkkitehtoninen näkökohta.
Yhtä tärkeää on ymmärtää välimuistiin tallentamisen keskeinen vaikeus — mitätöinti (välimuistin tyhjentäminen tai päivitys, kun data muuttuu, TTL:n tai eksplisiittisen poistamisen kautta, jotta vältytään vanhentuneista tiedoista) — sillä tässä tekeminen väärin on klassinen välimuistiin tallentamisen epäonnistuminen.
Tieto siitä, kuinka ja milloin soveltaa välimuistiin tallentamista, oikean välimuistin valitseminen käyttöympäristöä varten ja mitätöinnin oikea käsittely on arvokas senioritason tieto nopeien ja skaalattavien NestJS-palveluiden rakentamiseen.