L'integrazione di Redis nelle applicazioni NestJS trasforma le prestazioni sostituendo le chiamate al database con lookup in memoria. La combinazione di @nestjs/cache-manager per il caching e express-session con connect-redis per la persistenza delle sessioni copre i due casi d'uso Redis più comuni nelle applicazioni backend.

Concetto Chiave

Il caching Redis in NestJS riduce il carico sul database memorizzando i dati frequentemente accessibili in memoria. La gestione delle sessioni con Redis abilita la scalabilità orizzontale condividendo lo stato della sessione tra più istanze.

Configurazione di @nestjs/cache-manager con Redis

Il modulo cache-manager è stato spostato in un pacchetto separato in NestJS 10. L'installazione richiede sia il wrapper NestJS che lo store di cache sottostante. L'adapter @keyv/redis è l'approccio consigliato per l'integrazione Redis con cache-manager v5.

bash

# Installare i pacchetti richiesti
npm install @nestjs/cache-manager cache-manager @keyv/redis

La registrazione del modulo configura la connessione Redis e il TTL predefinito. L'opzione isGlobal rende la cache disponibile in tutti i moduli senza reimportarla.

app.module.tstypescript

import { Module } from '@nestjs/common';
import { CacheModule } from '@nestjs/cache-manager';
import KeyvRedis from '@keyv/redis';

@Module({
  imports: [
    CacheModule.registerAsync({
      isGlobal: true,
      useFactory: () => ({
        stores: [
          new KeyvRedis(process.env.REDIS_URL || 'redis://localhost:6379'),
        ],
        ttl: 60000, // TTL predefinito in millisecondi
      }),
    }),
  ],
})
export class AppModule {}

L'array stores accetta più store di cache per il caching multi-livello. Gli ambienti di produzione utilizzano tipicamente Redis come store primario, con un fallback in memoria opzionale per lo sviluppo.

Iniezione della Cache e Caching a Livello di Service

Il token CACHE_MANAGER fornisce accesso diretto alla cache per le operazioni a livello di service. Questo approccio offre maggiore controllo rispetto al caching HTTP automatico quando la logica di business determina l'invalidazione della cache.

users.service.tstypescript

import { Injectable, Inject } from '@nestjs/common';
import { CACHE_MANAGER, Cache } from '@nestjs/cache-manager';
import { UsersRepository } from './users.repository';
import { User } from './user.entity';

@Injectable()
export class UsersService {
  constructor(
    @Inject(CACHE_MANAGER) private cache: Cache,
    private usersRepository: UsersRepository,
  ) {}

  async findById(id: string): Promise<User | null> {
    // Controllare prima la cache
    const cacheKey = `user:${id}`;
    const cached = await this.cache.get<User>(cacheKey);
    
    if (cached) {
      return cached;
    }

    // Cache miss: recuperare dal database
    const user = await this.usersRepository.findById(id);
    
    if (user) {
      await this.cache.set(cacheKey, user, 300000); // TTL 5 minuti
    }

    return user;
  }

  async update(id: string, data: Partial<User>): Promise<User> {
    const user = await this.usersRepository.update(id, data);
    // Invalidare la cache in aggiornamento
    await this.cache.del(`user:${id}`);
    
    return user;
  }
}

Il pattern della chiave cache user:{id} permette l'invalidazione mirata. Pattern più complessi come user:* richiedono comandi specifici di Redis attraverso il client sottostante.

CacheInterceptor per il Caching Automatico delle Response HTTP

Il CacheInterceptor integrato memorizza automaticamente le response HTTP GET. L'applicazione a livello di controller memorizza tutti gli endpoint GET, mentre l'applicazione a livello di metodo fornisce controllo granulare.

products.controller.tstypescript

import { Controller, Get, UseInterceptors, Param } from '@nestjs/common';
import { CacheInterceptor, CacheTTL, CacheKey } from '@nestjs/cache-manager';
import { ProductsService } from './products.service';

@Controller('products')
@UseInterceptors(CacheInterceptor)
export class ProductsController {
  constructor(private productsService: ProductsService) {}

  @Get()
  @CacheTTL(120000) // Sovrascrivere TTL predefinito: 2 minuti
  async findAll() {
    return this.productsService.findAll();
  }

  @Get(':id')
  @CacheKey('product-detail') // Prefisso chiave cache personalizzato
  async findOne(@Param('id') id: string) {
    return this.productsService.findById(id);
  }
}

L'interceptor genera chiavi cache dall'URL della richiesta per impostazione predefinita. I decoratori @CacheKey() personalizzati sovrascrivono questo comportamento per le route dove i parametri di query non dovrebbero influenzare il caching. Per approfondimenti sugli interceptor e guard di NestJS, questi concetti appaiono frequentemente nei colloqui tecnici.

Collisioni delle Chiavi Cache

La chiave cache predefinita utilizza l'URL completo inclusi i parametri di query. Due richieste a /products?page=1 e /products?page=2 creano voci cache separate. Sovrascrivere con @CacheKey() quando la paginazione non dovrebbe creare response cached duplicate.

Gestione delle Sessioni con Redis ed express-session

NestJS viene eseguito su Express per impostazione predefinita, rendendo express-session la scelta standard per la gestione delle sessioni. L'adapter connect-redis memorizza i dati della sessione in Redis invece che in memoria, abilitando la persistenza della sessione attraverso i riavvii del server.

bash

# Installare i pacchetti per le sessioni
npm install express-session connect-redis redis
npm install -D @types/express-session

La configurazione della sessione avviene in main.ts prima dell'avvio dell'applicazione. Il client Redis si connette indipendentemente dalla configurazione di cache-manager.

main.tstypescript

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import * as session from 'express-session';
import { createClient } from 'redis';
import RedisStore from 'connect-redis';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);

  // Inizializzare il client Redis
  const redisClient = createClient({
    url: process.env.REDIS_URL || 'redis://localhost:6379',
  });
  await redisClient.connect();

  // Configurare il middleware di sessione
  app.use(
    session({
      store: new RedisStore({ client: redisClient }),
      secret: process.env.SESSION_SECRET || 'change-this-in-production',
      resave: false,
      saveUninitialized: false,
      cookie: {
        httpOnly: true,
        secure: process.env.NODE_ENV === 'production',
        maxAge: 24 * 60 * 60 * 1000, // 24 ore
      },
    }),
  );

  await app.listen(3000);
}
bootstrap();

L'opzione saveUninitialized: false impedisce la memorizzazione di sessioni vuote, riducendo l'utilizzo di memoria Redis. L'impostazione del cookie secure: true richiede HTTPS in produzione.

Pronto a superare i tuoi colloqui su Node.js / NestJS?

Pratica con i nostri simulatori interattivi, flashcards e test tecnici.

Esplora Node.js / NestJS

Accesso alle Sessioni in Controller e Guard

I dati della sessione sono disponibili attraverso l'oggetto request. Un'interfaccia di sessione tipizzata migliora l'esperienza dello sviluppatore e rileva gli errori in fase di compilazione.

session.interface.tstypescript

export interface SessionData {
  userId?: string;
  email?: string;
  roles?: string[];
  loginAt?: Date;
}

declare module 'express-session' {
  interface SessionData {
    userId?: string;
    email?: string;
    roles?: string[];
    loginAt?: Date;
  }
}

Il tipo di sessione esteso rende disponibili le proprietà della sessione con autocompletamento.

auth.controller.tstypescript

import { Controller, Post, Body, Req, HttpCode } from '@nestjs/common';
import { Request } from 'express';
import { AuthService } from './auth.service';
import { LoginDto } from './dto/login.dto';

@Controller('auth')
export class AuthController {
  constructor(private authService: AuthService) {}

  @Post('login')
  @HttpCode(200)
  async login(@Body() loginDto: LoginDto, @Req() req: Request) {
    const user = await this.authService.validateUser(
      loginDto.email,
      loginDto.password,
    );

    // Memorizzare i dati utente nella sessione
    req.session.userId = user.id;
    req.session.email = user.email;
    req.session.roles = user.roles;
    req.session.loginAt = new Date();

    return { message: 'Login effettuato con successo' };
  }

  @Post('logout')
  @HttpCode(200)
  async logout(@Req() req: Request) {
    return new Promise((resolve, reject) => {
      req.session.destroy((err) => {
        if (err) reject(err);
        resolve({ message: 'Logout effettuato con successo' });
      });
    });
  }
}

Un guard protegge le route verificando la validità della sessione. Questo pattern si integra perfettamente con il sistema di autorizzazione e RBAC di NestJS.

session.guard.tstypescript

import { Injectable, CanActivate, ExecutionContext } from '@nestjs/common';
import { Request } from 'express';

@Injectable()
export class SessionGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    const request = context.switchToHttp().getRequest<Request>();
    return !!request.session?.userId;
  }
}

Strategie di Invalidazione della Cache per Applicazioni NestJS

L'invalidazione della cache è il problema più difficile nel caching. Tre strategie si applicano a scenari diversi:

Scadenza basata sul tempo (TTL) funziona per dati che cambiano in modo prevedibile o dove una leggera obsolescenza è accettabile. Cataloghi prodotti, valori di configurazione e contenuti pubblici rientrano in questo pattern.

Invalidazione basata su eventi cancella le voci cache quando i dati sottostanti cambiano. Questo richiede chiamate esplicite cache.del() nelle operazioni di aggiornamento e cancellazione.

Invalidazione basata su pattern rimuove più chiavi correlate. Redis supporta la cancellazione basata su pattern attraverso i comandi SCAN e DEL, ma cache-manager astrae questo.

cache-invalidation.service.tstypescript

import { Injectable, Inject } from '@nestjs/common';
import { CACHE_MANAGER, Cache } from '@nestjs/cache-manager';

@Injectable()
export class CacheInvalidationService {
  constructor(@Inject(CACHE_MANAGER) private cache: Cache) {}

  // Invalidazione singola chiave
  async invalidateUser(userId: string): Promise<void> {
    await this.cache.del(`user:${userId}`);
  }

  // Multiple chiavi correlate
  async invalidateUserRelated(userId: string): Promise<void> {
    const keys = [
      `user:${userId}`,
      `user:${userId}:profile`,
      `user:${userId}:preferences`,
    ];
    
    await Promise.all(keys.map((key) => this.cache.del(key)));
  }

  // Svuotare l'intera cache (usare con parsimonia)
  async clearAll(): Promise<void> {
    await this.cache.reset();
  }
}

Il metodo reset() cancella tutti i dati memorizzati nella cache, utile durante i deployment o le migrazioni dei dati ma pericoloso in produzione se chiamato accidentalmente.

Connection Pooling e Supporto Cluster Redis

I deployment in produzione richiedono il connection pooling per gestire efficientemente le richieste concorrenti. La libreria ioredis fornisce supporto cluster e connection pooling nativamente.

redis.config.tstypescript

import { Injectable } from '@nestjs/common';
import { ConfigService } from '@nestjs/config';
import Redis, { Cluster } from 'ioredis';

@Injectable()
export class RedisConfig {
  constructor(private configService: ConfigService) {}

  createClient(): Redis | Cluster {
    const clusterNodes = this.configService.get<string>('REDIS_CLUSTER_NODES');

    if (clusterNodes) {
      // Modalità cluster
      const nodes = clusterNodes.split(',').map((node) => {
        const [host, port] = node.split(':');
        return { host, port: parseInt(port, 10) };
      });

      return new Redis.Cluster(nodes, {
        redisOptions: {
          password: this.configService.get('REDIS_PASSWORD'),
        },
      });
    }

    // Modalità standalone
    return new Redis({
      host: this.configService.get('REDIS_HOST', 'localhost'),
      port: this.configService.get('REDIS_PORT', 6379),
      password: this.configService.get('REDIS_PASSWORD'),
      maxRetriesPerRequest: 3,
    });
  }
}

Per le applicazioni che utilizzano TypeORM o Prisma, le connessioni database e cache dovrebbero essere configurate separatamente con i propri connection pool.

Domande di Colloquio su NestJS e Redis

I colloqui tecnici sul caching Node.js coprono sia la comprensione concettuale che l'implementazione pratica. Queste domande appaiono frequentemente:

Perché usare Redis invece del caching in memoria?

Il caching in memoria non persiste attraverso i riavvii e non può essere condiviso tra più istanze. Redis fornisce persistenza, replica e stato condiviso per applicazioni scalate orizzontalmente. Il compromesso è la latenza di rete rispetto all'accesso alla memoria locale.

Come si differenzia cache-manager dall'uso diretto di Redis?

La libreria cache-manager fornisce un'API unificata attraverso diversi store di cache. Il passaggio dalla memoria a Redis richiede solo la modifica della configurazione dello store senza modificare il codice del service. L'uso diretto di Redis offre più funzionalità specifiche di Redis come pub/sub, sorted set e scripting Lua.

Cos'è il cache stampede e come si previene?

Il cache stampede si verifica quando una voce cache popolare scade e molte richieste concorrenti colpiscono il database simultaneamente. Le strategie di prevenzione includono:

Refresh basato su lock: Una richiesta aggiorna la cache mentre le altre attendono
Scadenza anticipata probabilistica: Refresh casuale prima della scadenza TTL
Refresh in background: Un processo separato aggiorna le voci in scadenza

Quando usare CacheInterceptor vs. caching a livello di service?

CacheInterceptor è adatto per endpoint GET stateless dove la response dipende solo dall'URL. Il caching a livello di service gestisce scenari dove l'invalidazione della cache deve avvenire su modifiche ai dati o dove operazioni non-GET necessitano di caching.

Come si prevengono gli attacchi di session fixation con le sessioni Redis?

Rigenerare l'ID di sessione dopo l'autenticazione. Chiamare req.session.regenerate() prima di memorizzare le credenziali utente per impedire agli attaccanti di utilizzare ID di sessione pre-autenticazione.

typescript

// Login sicuro con rigenerazione sessione
async login(@Body() loginDto: LoginDto, @Req() req: Request) {
  const user = await this.authService.validateUser(
    loginDto.email,
    loginDto.password,
  );

  return new Promise((resolve, reject) => {
    req.session.regenerate((err) => {
      if (err) reject(err);
      
      req.session.userId = user.id;
      req.session.email = user.email;
      resolve({ message: 'Login effettuato con successo' });
    });
  });
}

Insight per il Colloquio

I candidati senior spiegano i compromessi tra le strategie di caching. Un junior potrebbe dire "il caching migliora le prestazioni". Un senior spiega quando il caching aggiunge complessità senza beneficio, come con dati altamente personalizzati o che cambiano rapidamente.

Monitoraggio delle Prestazioni e Metriche Redis

Le applicazioni in produzione necessitano visibilità sulle prestazioni della cache. Le metriche chiave includono:

Hit rate: Percentuale di richieste servite dalla cache. Sotto l'80% suggerisce problemi con TTL o strategia delle chiavi.
Utilizzo memoria: Il comando Redis INFO memory mostra memoria corrente e di picco.
Conteggio connessioni: Troppe connessioni indicano connection pooling mancante.
Conteggio eviction: Eviction non nulle significano che la cache è piena e sta eliminando voci.

redis-health.service.tstypescript

import { Injectable } from '@nestjs/common';
import Redis from 'ioredis';

@Injectable()
export class RedisHealthService {
  constructor(private redis: Redis) {}

  async getMetrics() {
    const info = await this.redis.info('stats');
    const memory = await this.redis.info('memory');
    
    const stats = this.parseInfo(info);
    const mem = this.parseInfo(memory);

    const hits = parseInt(stats.keyspace_hits, 10);
    const misses = parseInt(stats.keyspace_misses, 10);
    const hitRate = hits / (hits + misses) || 0;

    return {
      hitRate: (hitRate * 100).toFixed(2) + '%',
      usedMemory: mem.used_memory_human,
      connectedClients: stats.connected_clients,
      evictedKeys: stats.evicted_keys,
    };
  }

  private parseInfo(info: string): Record<string, string> {
    return info.split('\n').reduce((acc, line) => {
      const [key, value] = line.split(':');
      if (key && value) acc[key.trim()] = value.trim();
      return acc;
    }, {} as Record<string, string>);
  }
}

Esporre queste metriche attraverso un endpoint di health check o integrare con Prometheus per il monitoraggio in produzione.

Caching Redis e Sessioni nei Deployment NestJS in Produzione

Il deployment di NestJS con Redis richiede attenzione a diverse considerazioni operative:

Gestione delle connection string: Memorizzare gli URL Redis nelle variabili di ambiente, non nel codice. Utilizzare la gestione dei secret per le password.
Graceful shutdown: Chiudere le connessioni Redis durante lo shutdown dell'applicazione per prevenire leak di connessioni.
Logica di retry: Configurare exponential backoff per i fallimenti di connessione Redis.
Istanze Redis separate: Considerare istanze Redis separate per cache e sessioni. L'eviction della cache non dovrebbe influenzare i dati della sessione.

graceful-shutdown.tstypescript

import { Injectable, OnModuleDestroy } from '@nestjs/common';
import Redis from 'ioredis';

@Injectable()
export class RedisCleanup implements OnModuleDestroy {
  constructor(private redis: Redis) {}

  async onModuleDestroy() {
    await this.redis.quit();
  }
}

Per le architetture a microservizi, Redis serve anche come message broker attraverso il layer di trasporto integrato di NestJS, unificando caching, sessioni e comunicazione inter-service.