Πώς προσθέτετε caching στο NestJS;

Question

Accepted Answer

Το NestJS παρέχει ένα ενσωματωμένο **caching module** (`@nestjs/cache-manager`) με ένα ενοποιημένο API που λειτουργεί σε διάφορα stores — in-memory από προεπιλογή, ή **Redis** για κατανεμημένο caching σε πολλαπλές instances. Το caching βελτιώνει δραματικά την απόδοση αποφεύγοντας επαναλαμβανόμενη δύσκολη δουλειά.

## Ρύθμιση του cache module

```ts
@Module({
  imports: [
    CacheModule.register({
      ttl: 60000,        // default time-to-live (ms) — entries expire after 60s
      max: 100,          // max items in memory (in-memory store)
      isGlobal: true,    // available app-wide
    }),
  ],
})
export class AppModule {}
```

## Auto-caching endpoints με το interceptor

```ts
@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` αποθηκεύει αυτόματα τις απαντήσεις των `GET` endpoints (με κλειδί το URL) και εξυπηρετεί τα αποθηκευμένα αποτελέσματα σε επαναλαμβανόμενα αιτήματα — ο απλούστερος τρόπος για να κάνετε cache τα read-heavy endpoints.

## Manual caching με το CacheManager (περισσότερος έλεγχος)

```ts
@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` δίνει πλήρη έλεγχο — το get-or-fetch pattern (έλεγχος cache, fallback στην πηγή, αποθήκευση αποτελέσματος) για caching συγκεκριμένων δύσκολων λειτουργιών.

## Κατανεμημένο caching με Redis (πολλαπλές instances)

```ts
CacheModule.registerAsync({
  useFactory: async () => ({
    store: await redisStore({ url: process.env.REDIS_URL }),   // use Redis as the store
    ttl: 60000,
  }),
});
```

Το ίδιο API, υποστηριζόμενο από **Redis**, δίνει ένα **κοινό** cache σε όλες τις instances της εφαρμογής — απαραίτητο όταν εκτελείτε πολλαπλές instances (ένα in-memory cache δεν είναι κοινό μεταξύ τους).

## Το δύσκολο μέρος: cache invalidation

```ts
async updateProduct(id: string, data) {
  await this.db.update(id, data);
  await this.cache.del(`product:${id}`);   // INVALIDATE on change → avoid stale data
}
```

```text
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 είναι μία από τις αποδόσεις υψηλότερης επιπτώσεως για back-end εφαρμογές, και το ενσωματωμένο caching module του NestJS το κάνει καθαρό και συνεπές.

Η κατανόηση του είναι σημαντική επειδή τα read-heavy APIs επωφελούνται πολύ από το caching δύσκολων λειτουργιών (database queries, εξωτερικές κλήσεις API, υπολογισμοί) — μειώνοντας δραματικά την καθυστέρηση και το φορτίο.

Το NestJS προσφέρει τόσο απλό auto-caching (το `CacheInterceptor` για GET endpoints) όσο και λεπτομερή manual έλεγχο (το get-or-fetch pattern του `CACHE_MANAGER` για συγκεκριμένες λειτουργίες).

Κρίσιμα, το ενοποιημένο API λειτουργεί με διάφορα stores, γι' αυτό το ίδιο κώδικα μπορεί να χρησιμοποιεί **in-memory caching** (γρήγορο, μία instance) ή **Redis** (ένα κοινό cache σε πολλαπλές instances) — και το γεγονός ότι ένα in-memory cache *δεν είναι κοινό* κατά τη scaling οριζόντια (απαιτώντας Redis για κατανεμημένο caching) είναι σημαντικό αρχιτεκτονικό σημείο.

Εξίσου σημαντικό είναι η κατανόηση της κεντρικής δυσκολίας του caching — **invalidation** (εκκαθάριση ή ενημέρωση του cache όταν αλλάζουν τα δεδομένα, μέσω TTL ή ρητής διαγραφής, για να αποφύγετε την εξυπηρέτηση παλιών δεδομένων) — καθώς το να το κάνετε λάθος είναι το κλασικό αποτυχημένο caching.

Η γνώση του πώς και πότε να εφαρμόζετε caching, η επιλογή του σωστού store για την ανάπτυξη, και ο σωστός χειρισμός της invalidation είναι πολύτιμη γνώση ανώτερου επιπέδου για την κατασκευή γρήγορων και scalable NestJS services.