NestJS fournit un module de mise en cache intégré (@nestjs/cache-manager) avec une API unifiée qui fonctionne sur différents magasins — en mémoire par défaut, ou Redis pour la mise en cache distribuée sur plusieurs instances. La mise en cache améliore dramatiquement les performances en évitant les travaux coûteux répétés.
({
: [
.({
: ,
: ,
: ,
}),
],
})
{}
@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
}
}
L'CacheInterceptor met automatiquement en cache les réponses des endpoints GET (indexées par URL) et sert les résultats en cache lors des demandes répétées — le moyen le plus simple de mettre en cache les endpoints à lecture intensive.
@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;
}
}
Injecter CACHE_MANAGER donne un contrôle total — le pattern get-or-fetch (vérifier le cache, revenir à la source, stocker le résultat) pour mettre en cache les opérations coûteuses spécifiques.
CacheModule.registerAsync({
useFactory: async () => ({
store: await redisStore({ url: process.env.REDIS_URL }), // use Redis as the store
ttl: 60000,
}),
});
La même API, soutenue par Redis, fournit un cache partagé sur toutes les instances d'application — essentiel lors de l'exécution de plusieurs instances (un cache en mémoire n'est pas partagé entre elles).
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.
La mise en cache est l'une des optimisations de performance ayant le plus d'impact pour les applications back-end, et le module de mise en cache intégré de NestJS la rend propre et cohérente.
La comprendre est important car les API à lecture intensive bénéficient énormément de la mise en cache des opérations coûteuses (requêtes de base de données, appels d'API externes, calculs) — réduisant dramatiquement la latence et la charge.
NestJS offre à la fois une mise en cache automatique simple (l'CacheInterceptor pour les endpoints GET) et un contrôle fin et granulaire (le pattern get-or-fetch du CACHE_MANAGER pour des opérations spécifiques).
Crucifixalement, l'API unifiée fonctionne avec différents magasins, donc le même code peut utiliser la mise en cache en mémoire (rapide, une seule instance) ou Redis (un cache partagé sur plusieurs instances) — et savoir qu'un cache en mémoire n'est pas partagé lors de la mise à l'échelle horizontale (nécessitant Redis pour la mise en cache distribuée) est un point architectural important.
Également important est la compréhension de la difficulté centrale de la mise en cache — l'invalidation (vider ou mettre à jour le cache lorsque les données changent, via TTL ou suppression explicite, pour éviter de servir des données obsolètes) — car une mauvaise gestion est l'échec classique de la mise en cache.
Savoir comment et quand appliquer la mise en cache, choisir le bon magasin pour le déploiement, et gérer correctement l'invalidation est une connaissance précieuse de niveau senior pour construire des services NestJS rapides et évolutifs.