Feature request: Server-side caching for Trakt API responses

[stremiolabar]

Problem

When multiple users request the same Trakt public list (e.g., traktpublic_snoak_trending-movies), each request triggers a separate Trakt API call. Since Trakt's rate limit is 1,000 GET calls per 5 minutes per API key, and the Client ID is shared across all users of an instance, this quota gets exhausted quickly on popular instances like elfhosted.

When the rate limit is hit, fetchTraktListItems returns null, which results in empty catalog responses ({ metas: [] }) with no retry or fallback. Users see empty catalogs until the rate limit window resets.

Current behavior

• HTTP Cache-Control: max-age=300 tells the Stremio client to cache for 5 minutes (client-side only)
• No server-side caching exists for Trakt list responses
• No retry or backoff on HTTP 429 from Trakt
• The manifest cache (in-memory Map, 5min TTL) only caches the manifest, not catalog content

Suggested improvement

Add server-side caching for Trakt API responses using the existing src/utils/cache.js Cache class (which is already used by MDBList and search but not Trakt). For example:

Cache Trakt list responses server-side with a 5-minute TTL (matching the client-side cache). This way, 1,000 users requesting the same list = 1 Trakt API call instead of 1,000.