Skip to content

feat: optional response caching via DI (ITvdbCache) — no-op by default, cache-call when registered #9

Description

@ChrisonSimtian

Description

TheTVDB recommends callers cache/proxy responses; today this client is deliberately AS IS with none. Add an opt-in caching layer via DI using our own ITvdbCache abstraction:

  • If no ITvdbCache is registered → live calls (current behaviour).
  • If one is registered → cache-call (serve from cache, else fetch + store).

Pattern (the clean way)

Null Object + a caching DelegatingHandler — DI-native, composes with the existing auth (and envelope-unwrap) handlers in the HttpClient pipeline:

  • ITvdbCache (in TvdbClient.Abstractions) — TryGetAsync(key) / SetAsync(key, value, ttl).
  • NoOpTvdbCache — pass-through; registered by AddTvdbClient via TryAddSingleton<ITvdbCache, NoOpTvdbCache>() so a consumer-registered implementation wins.
  • CachingHandler : DelegatingHandler — keys on request method+URI; on GET, serves a cached response or forwards + stores. No-op cache ⇒ effectively transparent.

Consumer usage:

services.AddSingleton<ITvdbCache, MyRedisTvdbCache>();  // opt in
services.AddTvdbClient(config);                          // no-op stays if the above is absent

Notes / open questions

  • Cache key + TTL policy (per-endpoint? honor any Cache-Control TheTVDB sends?).
  • HTTP-level (handler, caches the raw enveloped body — simplest) vs typed-level (caches deserialized DTOs).
  • Ship as part of the core, or a separate TvdbClient.Caching package with in-memory + a sample distributed impl.

🤖 Generated with Claude Code

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions