Cache Subscriber Laravel Package

Product Decisions This Supports

• Caching policy for outbound HTTP calls, not a caching implementation. This package is a Guzzle middleware that stores and replays HTTP responses (a "private transparent proxy cache"). The product decision it informs is: which third-party API calls are safe to cache, for how long, and keyed on what — not "which library do we install." Treat it as a design reference for that policy, not as a dependency.
• Third-party API cost and quota management. If your roadmap includes integrations with metered APIs (maps, enrichment, shipping rates, tax, FX, geocoding, LLM providers billed per token), a response cache is the cheapest lever for cutting spend and staying inside rate limits. This package demonstrates the shape of that lever; the decision it supports is "do we cache at the HTTP layer, the service layer, or not at all?"
• Latency and resilience budget. Caching upstream responses lets you serve reads when a vendor is degraded. That is a reliability feature decision (graceful degradation vs. hard dependency), and it belongs in the roadmap discussion alongside retries and circuit breakers, not buried in an integration ticket.
• Build vs. buy for a shared HTTP client layer. If you are standardizing on Laravel's Http facade / Guzzle across many integrations, this package is evidence for building a thin, first-party caching wrapper you control — because the ecosystem's canonical options here are abandoned or unmaintained.
• Cache invalidation as a product requirement. Transparent HTTP caching forces you to answer "how stale may this be?" per integration. That is a product question with user-visible consequences (stale prices, stale inventory, stale entitlements) and should be surfaced as an explicit per-integration policy table rather than left to a default TTL.
• Priority signal, not a delivery candidate. With 63 stars, 0 dependents, an archived repo, and a last release in September 2019, the opportunity score is low. It is a reference architecture for a spike, not a line item on the roadmap.

Use cases it legitimately illustrates: idempotent GETs against read-mostly vendor endpoints, per-user vs. shared cache keying, honoring Cache-Control/ETag/Vary from upstream, and storing responses in PSR-6-compatible backends (Redis, filesystem) so cache state survives deploys.

When to Consider This Package

Criteria for adoption — essentially none for new work. Only consider it if all of the following are true:

• You are already locked to Guzzle 5 on a legacy service and cannot upgrade.
• The integration is read-only, idempotent, and tolerant of stale data.
• You accept that you are adopting an archived, deprecated package with no security patching and will vendor/fork it under MIT terms.
• You have an internal owner who will carry that fork and re-review it against CVEs in Guzzle 5 and its transitive dependencies.

When to look elsewhere — the default path:

• Any greenfield Laravel work. Use Laravel 10/11's Http client with a first-party cache decorator, or kevinrob/guzzle-cache-middleware (actively maintained, Guzzle 6/7, PSR-16 storage) if you want an off-the-shelf middleware.
• You want application-level caching, not transport-level. Cache::remember() around a small repository/service class is easier to test, easier to invalidate, and does not couple your cache keys to HTTP semantics.
• You need correctness guarantees. Transparent HTTP caching is a poor fit for authenticated, per-user, personalized, or rapidly changing data; cache-key collisions and Vary mishandling here become data-leak or stale-entitlement bugs that are expensive to find.
• You need a supported dependency. Archived repositories fail procurement, security review, and SOC2-style vendor questionnaires outright.
• You need PHP 8.1+ / modern static analysis. A Guzzle 5-era package will drag in old constraint sets and trip dependency resolution.

Practical trigger: if a spike shows a metered third-party API is a top-5 cost line or a top-3 p95 latency contributor, act on it — but with a maintained library, not this one. If neither is true, deprioritize the whole caching conversation.

How to Pitch It (Stakeholders)

To executives (30 seconds): We evaluated a library for caching responses from external APIs — the kind of thing that lowers vendor bills and makes our pages faster when a partner is slow. This specific package is archived, unmaintained since 2019, and has no adopters in the ecosystem, so we are not putting it in production. Its value to us is as a blueprint: it tells us exactly which levers exist and what governance we need. Recommendation: do not adopt; fund a small, owned caching layer in our HTTP client instead. Cost is measured in days, not a dependency risk.

To engineering: The package is a Guzzle 5 middleware implementing a private transparent proxy cache — it stores GET responses keyed by URL plus Vary, honors upstream Cache-Control/ETag, and persists to a PSR-6 pool. The pattern is sound; the artifact is not. Concretely: it is [DEPRECATED], the repo is archived, the last release was 2019-09-16, and it has zero dependents — which means no one is exercising it against current Guzzle, PHP 8, or current cache backends. If we want this behavior, implement it as a thin middleware or decorator over Illuminate\Support\Facades\Http using the framework's cache repository, with an explicit per-integration policy: key composition (including tenant/user when responses are personalized), TTL, whether to serve stale on upstream failure, and whether to bypass entirely for mutating or auth-sensitive calls. Ship it with hit-rate, latency-delta, and vendor-spend metrics from day one so we can prove the win and catch stale-data incidents early. Reserve one review per quarter so the layer does not silently rot the way this package did.

Risk summary to keep on the record: deprecated and archived; no security patching; Guzzle 5-only and therefore a PHP-version and dependency-resolution liability; zero dependents means zero ecosystem validation; transparent HTTP caching is a poor fit for authenticated or personalized responses and a common source of stale-data and cache-key bugs.