[RFC] Caching Module (cache-manager Integration)

[Evanion]

Overview

A module to provide caching capabilities (in-memory, Redis, etc.) for NexusDI, built on top of cache-manager. This approach leverages cache-manager’s robust, tiered caching and multi-backend support, while exposing a DI-friendly API and decorator-based caching for services.

Motivation

• Easy DI for cache clients: Make it simple to inject and mock cache clients in services.
• Declarative caching: Use decorators for method-level caching, reducing boilerplate.
• Support for multiple backends: Instantly support memory, Redis, Memcached, Mongo, and more via Keyv adapters.
• Tiered/multi-store caching: Let cache-manager handle store selection, TTLs, and fallbacks.
• Extensibility: Enable custom cache strategies and advanced features by passing options directly to cache-manager.

Proposed Features

• Use cache-manager as the underlying cache abstraction.
• Register cache backends and tiered caches via config (e.g., in container.json).
• Inject cache clients/services into providers using @InjectCache().
• Support for multiple named caches (e.g., default, session, etc.).
• @Cacheable() decorator for methods to cache results.
• Support for TTL, cache invalidation, and custom cache keys.
• Pass all options/config down to cache-manager for full feature access.
• Easy mocking/overriding of cache for testing.

Example Workflow

1. Configure the cache module in container.json:

   {
     "cache": {
       "default": {
         "stores": [
           { "backend": "memory", "ttl": 60 },
           { "backend": "redis", "url": "redis://localhost:6379", "ttl": 300 }
         ]
       },
       "session": {
         "stores": [
           { "backend": "redis", "url": "redis://localhost:6379", "ttl": 3600 }
         ]
       }
     }
   }

2. Register the cache module:

   import { CacheModule } from '@nexusdi/cache';
   
   container.set(CacheModule.configFromFile('container.json'));

3. Inject cache clients and use decorators:

   import { InjectCache, Cacheable } from '@nexusdi/cache';
   
   class ProductService {
     constructor(@InjectCache() private cache: Cache) {}
   
     @Cacheable({ ttl: 120 })
     async getProduct(id: string) {
       // fetch product from DB or API
     }
   }
   
   class SessionService {
     constructor(@InjectCache('session') private sessionCache: Cache) {}
   
     async getSession(sessionId: string) {
       return this.sessionCache.get(sessionId);
     }
   }

Store Selection and Tiered Caching

• When you configure multiple stores for a cache, cache-manager treats them as a tiered cache (e.g., memory first, Redis as fallback).
• You interact with the cache as a whole; cache-manager handles which store to use for reads/writes and manages TTLs.
• If you need multiple independent caches (e.g., for different data domains), configure and inject named caches (e.g., default, session).

Open Questions

• Which cache-manager features should be surfaced in the DI API?
• Any backends or adapters you want prioritized for first-class support?
• Any pain points with cache-manager you’d like to see improved in a DI context?
• Should we provide additional decorators for cache invalidation or busting?
• How to best support mocking/overriding cache for testing?

API Sketch

import { InjectCache, Cacheable } from '@nexusdi/cache';

class ProductService {
  constructor(@InjectCache() private cache: Cache) {}

  @Cacheable({ ttl: 120 })
  async getProduct(id: string) {
    // fetch product from DB or API
  }
}

class SessionService {
  constructor(@InjectCache('session') private sessionCache: Cache) {}

  async getSession(sessionId: string) {
    return this.sessionCache.get(sessionId);
  }
}

Call for Feedback

• What cache backends do you use or want supported?
• What features or decorators would you want for caching?
• Any pain points with caching in DI frameworks or with cache-manager?
• How important is support for cache invalidation, custom keys, or advanced features?
• Any other features or decorator options you’d want?