NestJS ponuja vgrajeni modul za predpomnilnik (@nestjs/cache-manager) z enotnim API-jem, ki deluje na različnih skladiščih — privzeto v pomnilniku ali Redis za distribuirani predpomnilnik na več primerkih. Predpomnilnik dramatično izboljša zmogljivost z izogibanjem ponavljajočemu se dragocenemu delu.
({
: [
.({
: ,
: ,
: ,
}),
],
})
{}
@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 avtomatično predpomniluje odzive GET končnih točk (ključane po URL-ju) in streže predpomnilnikovane rezultate pri ponovnih zahtevkih — najpreprostejši način za predpomniliranje končnih točk z ogromno branjem.
@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;
}
}
Vstavlja CACHE_MANAGER daje polno nadzor — vzorec get-or-fetch (preverite predpomnilnik, padite nazaj na vir, shranite rezultat) za predpomniliranje specifičnih dragocenih operacij.
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
Enaki API, podprt z Redis-om, daje skupni predpomnilnik na vseh primerkih aplikacije — bistven, ko tečete več primerkov (predpomnilnik v pomnilniku ni skupni med njimi).
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.
Predpomnilniranje je ena od vrst optimizacij zmogljivosti z največjim vplivom za back-end aplikacije, in vgrajeni modul za predpomnilniranje NestJS-a ga naredi čist in dosleden.
Razumevanje je pomembno, ker API-ji z ogromno branjem ogromno koristijo od predpomnilniranja dragocenih operacij (poizvedbe v podatkovni bazi, klici zunanjih API-jev, izračuni) — dramatično zmanjšajo zakasnitev in obremenitev.
NestJS ponuja tako enostavno avtomatsko predpomniliranje (CacheInterceptor za GET končne točke) kot tudi fino-zrnati ročni nadzor (vzorec CACHE_MANAGER get-or-fetch za specifične operacije).
Udeleženi je enotni API, ki deluje z različnimi skladišči, zato ista koda lahko uporablja predpomnilniranje v pomnilniku (hitro, en primerek) ali Redis (skupni predpomnilnik na več primerkih) — in vedenje, da predpomnilnik v pomnilniku ni skupni, ko se horizontalno skalira (zahtevajući Redis za distribuirani predpomnilnik), je pomembna arhitekturna točka.
Enako pomembno je razumevanje osrednjega preklica predpomnilnika — preklica (brisanje ali posodobitev predpomnilnika, ko se podatki spremenijo, prek TTL-ja ali izričitega brisanja, da se izognete serviranju zastarelih podatkov) — saj je napačno narediti to je klasičen krah predpomnilnika.
Znanje kako in kdaj uporabiti predpomnilniranje, izbiro pravega skladišča za postavitev in pravilno obravnavo preklica je dragoceno znanje višje ravni za gradnjo hitrih, razširljivih NestJS storitev.