Rememberable Query Laravel Package

Product Decisions This Supports

• Closing a known DX gap in our Laravel stack. Eloquent has no first-class "cache this query's results" primitive — teams today wrap queries in Cache::remember(...) closures, hand-roll cache keys, or reach for staudenmeir/laravel-caching-query. This package demonstrates a one-line ergonomic (Post::remember(60)->where(...)->get()) that removes that boilerplate, which is a real developer-experience win on read-heavy endpoints.
• Prioritising read-path performance work. Useful for scoping where query-result caching would pay off first: dashboards, public listing pages, reference/lookup tables, and config-like data that changes on a schedule rather than per-request. Good input into a "cache the top N expensive queries" roadmap item.
• Build vs. buy framing — and the answer here is "build small." The capability is genuinely valuable; the artefact is not. This is a ~200-line trait over Illuminate\Cache. The PM decision is to adopt the pattern, not the dependency: spec a first-party trait behind our own namespace, with our key-prefix, TTL, and invalidation conventions baked in.
• Invalidation design, which is the actual product problem. Caching is easy; deciding when results go stale is not. Any feature here forces a decision on tag-based flushing (Redis/Memcached only — note the file and database cache drivers don't support tags), model-event-driven invalidation, or blunt TTLs. This is the real roadmap conversation this package surfaces.
• Not a candidate for a dependency-review ticket. With zero dependents, no commits since early 2022, and an archived repo, adopting it would add a supply-chain and security-review burden with no upstream to escalate to.

When to Consider This Package

Consider the approach when:

• You have read-heavy, low-write Eloquent queries — catalogues, settings, category trees, public marketing pages — where a 60-second stale window is a business-acceptable trade.
• Your cache store supports tags (Redis, Memcached), so you can invalidate coherently; without tags the ergonomics collapse quickly.
• Your team is small enough that a 40-line internal trait is cheaper to own than a dependency is to vet.

Look elsewhere — or rather, do not adopt this specific package — because:

• It is archived. No security patches, no Laravel 11/12 compatibility work, no response to a breaking change in the framework's query builder internals. Eloquent's Builder has changed meaningfully since 2022; assume it needs verification and likely patching before it runs on a current version.
• Pre-1.0 community signal. 48 stars, zero dependents, no ecosystem validation. There is no meaningful peer evidence that this survives production contact.
• The cost/benefit is inverted. Vendoring or reimplementing is a half-day; adopting, wrapping, and monitoring a dead package is a recurring tax with a single point of failure at its centre.
• You need fine-grained invalidation. If your domain requires precise cache busting on writes, a query-level remember() trait is the wrong abstraction — prefer explicit repository-level caching or Laravel's Cache::flexible/Cache::remember at a service boundary where you control the key and the flush.
• Correctness is subtle. Eloquent results cache the hydrated models, so cached collections can hold stale attribute values and stale relations. If your queries are tenant-scoped, user-scoped, or permission-filtered, a naive remember() risks cross-tenant leakage through key collisions — a class of bug worth avoiding entirely.

How to Pitch It (Stakeholders)

To executives: We found a small open-source package that solves a real and common problem — making database query results cheap to cache. The idea is sound and worth copying; the package itself is abandoned, unmaintained since 2022, and used by nobody. My recommendation is a short internal build (roughly half a day of engineering) rather than taking on a dead dependency. Expected outcome is fewer database round-trips on our read-heavy screens, no added supply-chain risk, and no licence or vendor exposure.

To engineering: This is the one-line query-caching ergonomic we keep re-writing by hand. Don't take the dependency — it's archived, unpatched, and untested against current Laravel. Instead, let's lift the pattern into a RememberableQuery trait we own: remember($ttl, $tags = null) on the Eloquent builder, delegating to Cache::tags() when the store supports it, defaulting to a namespaced cache key derived from the SQL and bindings, and a documented posture that cached results may hold stale model attributes. We own the invalidation contract, we control the key namespace, and we can add an escape hatch (->fresh(), a withoutRemember() scope) from day one. Estimate: one spike to confirm the builder hook, one PR to ship, plus tests for tag flushing and tenancy-scoped keys.