Http Cache Laravel Package

Technical Evaluation

Architecture fit. slim/http-cache is a Slim-ecosystem HTTP caching layer: a PSR-7 response decorator (Slim\HttpCache\Cache) plus PSR-15 middleware that emits Cache-Control, Expires, ETag, and Last-Modified and short-circuits to 304 Not Modified on conditional requests. Laravel is neither PSR-7 nor PSR-15 native — its middleware pipeline passes Illuminate\Http\Request and expects an Illuminate\Http\Response. The package therefore does not slot into a Laravel application without an adapter. Two viable placements: (a) a Laravel middleware that converts to/from PSR-7 via symfony/psr-http-message-bridge + nyholm/psr7 and delegates header construction; (b) out-of-band use in an actual Slim 4 microservice or a PSR-15 edge component. Everything else is a mismatch.

Integration feasibility. Low-to-moderate for Laravel, and the marginal value is close to zero. Laravel already ships Illuminate\Http\Middleware\SetCacheHeaders, Response::setEtag()/setLastModified(), and Symfony HttpFoundation's Response::isNotModified() conditional-request handling. The package's only distinct contribution is a fluent API for assembling cache headers on a PSR-7 response — a cosmetic gain that costs a bridge in the request hot path and a second, divergent implementation of cache semantics.

Technical risk. Dependency risk is small (MIT, thin PSR-interface surface). Strategic fit risk is high: 116 stars, 0 dependents, low composite score (2.33), and a maintenance cadence driven by the Slim maintainers rather than by demand. The 2025-11-05 release shows liveness but not adoption. Adopting it buys us a dead-end dependency for a capability the framework already provides.

Key questions.

• Is the driver genuinely a Slim service, or is this a mis-tagged candidate for a Laravel app? This is the go/no-go gate.
• What is the caching topology — application-level response cache, reverse proxy, or CDN edge? Most wins live at the edge, not in middleware.
• Who owns cache-key design, Vary policy, and invalidation triggers?
• Does the package cover Vary, s-maxage, and stale-while-revalidate, or only the basics?
• If a Laravel adapter is proposed: can spatie/laravel-responsecache, barryvdh/laravel-httpcache, or Symfony HttpCache meet the requirement with less surface area?

Integration Approach

Stack fit. Assume PHP 8.x + Composer. In a Slim 4 service: composer require slim/http-cache, register the middleware, set default TTL, done — roughly half a day. In Laravel: not a stack fit; treat any integration as a bespoke adapter project.

Migration path (ranked).

1. Native Laravel, no new dependency — SetCacheHeaders middleware plus Response::setEtag()/setLastModified(); route-level cache.headers:public;max_age=3600;etag. Preferred.
2. If full response-body caching is the requirement — spatie/laravel-responsecache (application cache) or Symfony HttpCache (reverse proxy in front of the kernel). Preferred over a PSR-7 bridge.
3. If a Slim service exists — adopt slim/http-cache there only, and keep it out of the Laravel codebase entirely.
4. Adapter last resort — thin Laravel middleware + PSR-7 bridge, timeboxed to 3–5 dev days, gated on a correctness suite: 304 round-trips, strong vs. weak ETag behavior, Vary handling, no body on 304, Content-Length accuracy.

Compatibility. PSR-7 implementations differ in stream and immutability behavior; verify Content-Length on 304 and stream rewind in the adapter path. Middleware ordering is decisive: cache middleware must run after response generation and before session/CSRF middleware that attach cookies. Responses carrying Set-Cookie or Authorization must be forced to private, no-store.

Sequencing. (1) Confirm Slim vs. Laravel — gate. (2) Inventory caching requirements: edge vs. app, TTL policy, invalidation triggers. (3) Pilot on one low-traffic Slim endpoint behind a flag. (4) Measure hit ratio and origin offload. (5) Decide fleet-wide. Do not sequence this ahead of CDN/edge caching work — the leverage is an order of magnitude larger there.

Operational Impact

Maintenance. Small codebase; ecosystem-driven release cadence; effectively no community signal at 0 dependents. Budget ~1–2 days/year for dependency bumps plus upkeep of our own adapter if one is built. Pin exact versions.

Support. MIT, community-only, no vendor. Internal ownership must be assigned — platform/API team — with a documented escalation path. The one mitigating factor: the surface is small enough that forking is a realistic fallback, so record that in the ADR rather than treating abandonment as a blocker.

Scaling. Header generation is O(1); expect no measurable CPU or latency delta (±1 ms). The real scaling variable is hit ratio, and the real risk is correctness. A misconfigured Vary or a leaked Set-Cookie produces cache poisoning or cross-user content leakage — a security incident, not a performance regression. Note also that caching shifts load from origin to cache tier, so capacity planning must move with it.

Failure modes.

• Stale content after deploy → requires deploy hooks and versioned ETags.
• 304 with a body or wrong Content-Length → broken clients and CDN misbehavior.
• private content cached publicly due to middleware ordering.
• Double caching (app + CDN) with mismatched TTLs → opaque invalidation.
• PSR-7 bridge exceptions or stream-rewind bugs, unique to the adapter path.
• Dependency abandonment → forced migration at an inconvenient time.

Ramp-up. Near-zero for a Slim engineer (idiomatic PSR-15, adequate README). For a Laravel team the cost is really PSR-7/PSR-15 literacy plus adapter debugging — 2–4 days for one engineer, spent learning a pattern the team does not otherwise use.

TPM recommendation. No for the Laravel path; conditional yes only for an existing Slim service. Effort: 0.5 day (Slim) vs. 3–5 days (Laravel adapter, not recommended). Technical risk low; strategic fit risk high.