NestJS zapewnia wbudowany moduł cachowania (@nestjs/cache-manager) z ujednoliconym API, które działa na różnych storage'ach — domyślnie w pamięci, lub Redis dla rozproszonego cachowania na wielu instancjach. Caching dramatycznie poprawia wydajność poprzez unikanie powtarzanego drogiego przetwarzania.
({
: [
.({
: ,
: ,
: ,
}),
],
})
{}
@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 automatycznie cachuje odpowiedzi GET endpointów (indeksowane po URL) i serwuje buforowane wyniki na powtarzające się żądania — najprostszy sposób na cachowanie endpointów czytających.
@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;
}
}
Wstrzyknięcie CACHE_MANAGER daje pełną kontrolę — wzorzec get-or-fetch (sprawdzenie cache'u, powrót do źródła, zapisanie wyniku) do cachowania specyficznych drogich operacji.
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
To samo API, wspierane przez Redis, daje wspólny cache na wszystkich instancjach aplikacji — niezbędne gdy uruchamiane są wiele instancji (cache w pamięci nie jest udostępniany między nimi).
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 jest jedną z optymalizacji wydajności o największym wpływie dla aplikacji backendowych, a wbudowany moduł cachowania NestJS czyni to czystym i konsystentnym.
Rozumienie tego jest ważne, ponieważ API intensywnie czytające czerpią ogromne korzyści z cachowania drogich operacji (zapytania do bazy danych, wywołania zewnętrznych API, obliczenia) — dramatycznie zmniejszając opóźnienie i obciążenie.
NestJS oferuje zarówno proste auto-cachowanie (CacheInterceptor dla GET endpointów) jak i precyzyjną ręczną kontrolę (wzorzec CACHE_MANAGER get-or-fetch dla specyficznych operacji).
Krytycznie, ujednolicone API działa z różnymi storage'ami, dlatego ten sam kod może wykorzystywać cachowanie w pamięci (szybkie, dla pojedynczej instancji) lub Redis (wspólny cache na wielu instancjach) — i wiedza, że cache w pamięci nie jest wspólny przy skalowaniu poziomym (wymagającym Redis dla rozproszonego cachowania) jest ważnym punktem architektonicznym.
Równie ważne jest zrozumienie centralnej trudności cachowania — unieważniania (czyszczenia lub aktualizowania cache'u gdy dane się zmieniają, poprzez TTL lub jawne usunięcie, aby uniknąć serwowania nieaktualnych danych) — ponieważ zrobienie tego źle jest klasyczną porażką cachowania.
Wiedza jak i kiedy zastosować caching, wybór odpowiedniego storage'u dla wdrożenia i prawidłowe obsługowanie unieważniania to cenna wiedza na poziomie senior dla budowania szybkich, skalowalnych usług NestJS.