Rememberable Laravel Package

Product Decisions This Supports

• Read-path performance and scalability roadmap. If the plan is to cut database load on read-heavy surfaces — catalogs, category trees, settings, CMS content blocks, reference/lookup tables — this package remains a candidate lever: it caches Eloquent query results and serves them from the configured cache store instead of hitting the database on every request. As of v3.0.0-beta1, the new "automatic query caching" mode means the lever can be pulled once at a base model rather than per call site, which raises both the potential payoff and the potential blast radius.
• Build vs. buy for caching. It frames a recurring decision: adopt a trait that restores Laravel 4-style remember() semantics, write Cache::remember() inline, use a maintained equivalent (watson/rememberable), or layer on a response cache. This package sits at the "small, cheap, single-purpose dependency" end of that spectrum — but the new default-on behavior pushes it toward "framework-ish" territory that a 10-star dependency hasn't earned.
• Feature-level caching policy — now the central decision. The beta's headline change ("no effort beyond adding it to a base model") converts caching from an opt-in, query-by-query decision into an opt-out, model-wide decision. That is a product call, not just a technical one: do we want caching applied by inheritance to every query a model emits, including ones we haven't profiled? The PM-level question shifts from "which models and queries get cached" to "what is our default caching posture, and who owns the exceptions?"
• Data-consistency and correctness posture. Automatic invalidation on model events remains the weak link, and base-model-level enablement widens it — queries that bypass model events (DB::table(), raw SQL, mass updates, queue workers, other services writing the same tables) will serve stale data for a full TTL. This directly informs which bounded contexts are safe to onboard (reference/lookup data) versus which are not (inventory, pricing, entitlements).
• Technical-debt and modernization input. The profile is unchanged in kind, only in degree: pre-1.0-style maturity signal (beta), no stated Laravel/PHP compatibility in the release notes, historical last release September 2016 before this, 10 stars, 0 dependents. A 3.0.0 major version bump implies breaking changes, so existing guidance and any prior integration notes are void. The need for query caching is validated; this vendor is still not a durable dependency — the roadmap item stays "adopt behind a kill switch, or replace/fork."
• Concrete use cases: API read endpoints with low write frequency, admin dashboards repeating the same aggregate queries, multi-page flows re-querying reference data, and MVP/prototype stages where implementation speed outweighs caching sophistication. The automatic mode makes the prototype case faster and the production case riskier in the same release.

When to Consider This Package

Consider it when:

• You are on the Laravel version this beta actually supports — and that must be verified in composer.json / CI, not inferred from the release note, which says nothing about framework or PHP compatibility. Prior guidance assumed Laravel 5.x only; v3.0.0-beta1 is a new, unverified baseline.
• Your use case matches the beta's design intent: a base model shared by low-churn, read-heavy models, where automatic caching of every emitted query is acceptable and TTL staleness plus event-driven invalidation clears your consistency bar.
• You are willing to treat beta software as beta software — pin the exact version, isolate it behind a config flag or a thin internal wrapper, and accept that a beta may change behavior or be abandoned mid-cycle.
• You want a small, MIT-licensed, single-purpose dependency short enough to read end-to-end and vendor or fork if needed.
• You are running a spike or proof of concept to quantify database-load reduction before committing to a real caching architecture — this is now the strongest reason to touch it.

Look elsewhere when:

• Compatibility is unconfirmed for your runtime. A beta release note that omits framework and PHP support is not a green light; treat it as unknown until the manifest is read.
• You need per-query control as the default — if you want caching to be an explicit, reviewed decision at each call site, the "no effort beyond a base model" model is the wrong ergonomics.
• You need cache tags, per-tenant keys, stampede protection, or cross-service invalidation — this is not that layer.
• Correctness is strict (inventory, pricing, permissions, entitlements): automatic invalidation on model events is easy to get subtly wrong, base-model-wide enablement multiplies the number of queries whose staleness you must reason about, and a beta with zero dependents has no community to surface the edge cases.
• Supply-chain or support risk matters — a beta of a near-abandoned package is a worse risk profile than a maintained equivalent (watson/rememberable) or native Cache::remember() at similar effort.
• The need is trivial — a handful of Cache::remember() calls beats adding a dependency with an uncertain maintenance story.

How to Pitch It (Stakeholders)

Executives: Query caching is still a cheap, high-leverage way to cut database load and improve response times on read-heavy parts of the product. The package just shipped a beta (v3.0.0-beta1) that makes caching fully automatic — add the trait to a base model and every query on that model is cached, with no per-query work. That is a genuine ergonomics win and it moves our prototype cost down. It does not change the lifecycle story: it is a beta from a package with 10 stars, zero dependents, and a prior release history ending in 2016, and the release note doesn't state which Laravel or PHP versions it supports. A major version number also means breaking changes, so anything we documented before is stale. Recommendation: hold the existing decision. Do not standardize on it. Fund the same short timeboxed experiment, now with an explicit rule that the beta stays behind a feature flag and is never switched on by default in production. If the numbers justify caching, implement it with a maintained package or roughly twenty lines of native Laravel caching. Low cost, contained risk — provided we treat the beta as a trial and not a decision.

Engineering:

• What it is: a Rememberable trait for Eloquent models that restores Laravel 4-style query caching, keyed off generated SQL and bindings, with cache invalidation hooked into model events. v3.0.0-beta1 adds automatic query caching — no ->remember($minutes) needed at call sites; inheritance from a base model is the only wiring.
• What's genuinely new: per-query opt-in becomes model-wide default-on. Fewer call-site edits and no chance of forgetting ->remember(), but every query a model emits is now cached, including ones nobody profiled, and every one of them depends on model events firing for invalidation.
• What's unresolved: framework/PHP compatibility is not stated in the release notes — verify against composer.json before writing any code. No CI or coverage signal mentioned. Beta means behavior and public API may still move. Major version bump implies breaking changes versus prior usage.
• Integration cost: one use statement on a base model, plus TTL configuration. No schema changes, no new infrastructure — but budget for the inverse work: an inventory of queries that must be excluded, and a mechanism (wrapper or trait override) to exclude them, since the beta's selling point is that you don't think about this per query.
• Risks: blanket caching widens staleness blast radius; writes that bypass Eloquent events (raw SQL, mass updates, other services, queue workers on shared tables) will not invalidate; beta plus zero dependents means we own every bug, including ones introduced in a future beta; no visible upstream support commitment.
• Ask: keep the two-day timeboxed spike on one read-heavy model set. Measure query counts and p95 latency before/after. Add three gates the beta makes necessary: (1) confirm declared Laravel/PHP support before starting; (2) confirm the automatic mode can be disabled per model and globally, and demo the kill switch; (3) run the staleness test — mutate rows outside Eloquent and verify how long stale reads persist. Evaluate watson/rememberable as the maintained alternative in parallel. Deliver a go/no-go with the maintenance- and correctness-risk tradeoff written down.