كيف تضيف التخزين المؤقت في NestJS؟

Question

Accepted Answer

يوفر NestJS **وحدة تخزين مؤقت مدمجة** (`@nestjs/cache-manager`) مع واجهة برمجية موحدة تعمل عبر أنظمة التخزين المختلفة — في الذاكرة بشكل افتراضي، أو **Redis** للتخزين المؤقت الموزع عبر عدة نسخ. يحسن التخزين المؤقت الأداء بشكل كبير بتجنب تكرار العمل المكلف.

## إعداد وحدة التخزين المؤقت

```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 {}
```

## التخزين المؤقت التلقائي للنقاط النهائية باستخدام الاعتراض

```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` مؤقتاً تلقائياً (مفهرسة حسب العنوان) وتقديم النتائج المخزنة مؤقتاً عند الطلبات المتكررة — الطريقة الأبسط لتخزين النقاط النهائية الثقيلة القراءة مؤقتاً.

## التخزين المؤقت اليدوي باستخدام 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 (التحقق من التخزين المؤقت، العودة إلى المصدر، تخزين النتيجة) لتخزين العمليات المكلفة المحددة مؤقتاً.

## التخزين المؤقت الموزع باستخدام Redis (عدة نسخ)

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

نفس الواجهة البرمجية، مدعومة بـ **Redis**، توفر **تخزين مؤقت مشترك** عبر جميع نسخ التطبيق — ضروري عند تشغيل عدة نسخ (التخزين المؤقت في الذاكرة لا يُشارك بينها).

## الجزء الصعب: إلغاء التخزين المؤقت

```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.
```

## لماذا يهم هذا

التخزين المؤقت هو أحد أعلى الاستثمارات الأثر لتحسين الأداء في تطبيقات الواجهة الخلفية، وتجعل وحدة التخزين المؤقت المدمجة في NestJS الأمر نظيفاً ومتسقاً.

فهمه مهم لأن واجهات برمجية ثقيلة القراءة تستفيد بشكل كبير من التخزين المؤقت للعمليات المكلفة (استعلامات قاعدة البيانات، استدعاءات واجهات برمجية خارجية، الحسابات) — مما يقلل زمن الوصول والحمل بشكل كبير.

يوفر NestJS كلاً من التخزين المؤقت التلقائي البسيط (`CacheInterceptor` لنقاط النهاية GET) والتحكم اليدوي الدقيق (نمط get-or-fetch `CACHE_MANAGER` للعمليات المحددة).

بشكل حاسم، تعمل الواجهة البرمجية الموحدة مع أنظمة تخزين مختلفة، لذا يمكن لنفس الكود استخدام **التخزين المؤقت في الذاكرة** (سريع، نسخة واحدة) أو **Redis** (تخزين مؤقت مشترك عبر عدة نسخ) — ومعرفة أن التخزين المؤقت في الذاكرة *لا يُشارك* عند التوسع الأفقي (يتطلب Redis للتخزين المؤقت الموزع) نقطة معمارية مهمة.

من المهم بنفس القدر فهم الصعوبة المركزية للتخزين المؤقت — **إلغاء التخزين المؤقت** (مسح أو تحديث التخزين المؤقت عند تغيير البيانات، عبر TTL أو الحذف الصريح، لتجنب تقديم بيانات قديمة) — لأن الحصول على هذا بشكل خاطئ هو فشل التخزين المؤقت الكلاسيكي.

معرفة كيفية ومتى تطبيق التخزين المؤقت، واختيار نظام التخزين المناسب للنشر، ومعالجة الإلغاء بشكل صحيح هي معرفة قيمة على مستوى أعلى لبناء خدمات NestJS سريعة وقابلة للتوسع.