Laravel Remember All Laravel Package

Technical Evaluation

Architecture fit. This is a read-path optimisation that sits inside the Eloquent query builder, not in the request lifecycle or the data model. It reintroduces an ergonomic, query-level caching primitive — the remember()-style API Laravel removed from the query builder back in 5.8 — and extends it two ways: a rememberAll() call that caches a full chain, and a global/per-model opt-in so no call sites change. For a TPM that means the blast radius is bounded to code that issues reads, there are no migrations, no schema changes, and no service provider behaviour that should alter boot or routing. The architectural concern is not integration surface, it is semantic surface: wrapping a query in a cache changes its consistency guarantees, and doing so globally means the decision is made once at config level and inherited silently by every read in the model.

Integration feasibility. Mechanically trivial — a Composer require, an optional config publish, an optional trait. The real feasibility question is framework currency. The package declares Laravel 8+ / PHP 8+ and its final release (2022-09-30) exists to add Laravel 9 support. It is archived, which is a hard fact, not an inference: there is no Laravel 10, 11, or 12 path, no PHP 8.2/8.3 validation, and no security response channel. On a Laravel 8/9 estate it will install; on anything newer it is either unresolvable or resolving-but-unverified, which is worse. Treat the supported window as closed at L9.

Technical risk. Four risks dominate, in descending order of business impact.

1. Staleness with no invalidation contract. The description specifies keys from SQL plus bindings and invalidation by TTL only. There is no described hook into model events, so a write does not evict the read cache. For any read that must reflect a just-committed write — an eligibility check, a balance, an authorisation lookup, a workflow state — this silently converts a strong read into a stale read. Global mode makes this the default across the whole model, including paths nobody audited.
2. Cache key correctness under multi-tenancy. Keys derived from SQL and bindings are only tenant-safe if every tenant-scoped query binds a tenant identifier. Any query relying on session, global scope, or connection-level tenancy that is not in the binding set can collide across tenants. That is a data-leak class of bug, not a performance bug.
3. Abandonment. Archived + 29 stars + zero releases in over two years. There will be no fix if a framework upgrade breaks it, and no advisory if a flaw is found. This is the risk that decides the others, because it means the team owns the code whether or not it owns the repo.
4. Cache-layer amplification. A TTL-only scheme with per-query keys generates high key cardinality and a synchronised expiry wave — the classic stampede where a popular model's cache expires and the full read load lands on the database at once. Global mode turns a modest number of instrumented reads into a very large number of cached ones, which is a capacity-planning change to Redis, not just an application change.

Key questions.

• Which of our reads are consistency-tolerant, and can we enumerate them? If we cannot, global mode is not available to us and only explicit call-site opt-in is.
• Does every tenant-scoped query bind its tenant identifier, or do some rely on global scopes? This is a security review question, not a performance one.
• What is the actual code surface — one trait, one macro, one service provider — and is it small enough to vendor or reimplement in-house at low cost?
• Does the implementation degrade gracefully when the cache store is unavailable (fall through to the database) or does it fail the request?
• Are TTL and cache store per-model configurable, or only globally?
• Is the package pinned in composer.json anywhere in the estate today, and if so, which services and which framework versions?

Integration Approach

Stack fit. Only viable on Laravel 8 or 9 with PHP 8.x, and only for read-heavy, consistency-tolerant workloads — reporting, catalogue and listing pages, reference data, dashboards, search facets. It is explicitly not a fit for anything on a Laravel 10+ upgrade path, because adopting it there creates a dependency we know we must remove within the planning horizon. That single constraint should decide the decision for most estates: adopting an archived package as you move forward in framework versions buys a short-term latency win for a guaranteed future migration.

Migration path. Do not adopt this as a long-lived dependency. The correct framing is buy-time, not build-time: use it to close a specific latency gap inside one release cycle, with a pre-agreed exit. Concretely:

1. Read the source. It is small. Confirm the cache key construction, the TTL resolution order, the store resolution, and the fallback behaviour when the store is unreachable. Confirm whether rememberAll() is a builder macro or a trait method, because that determines whether it composes with our existing scopes and pagination.
2. Decide the abstraction boundary before writing any call sites. If we adopt, we adopt behind an internal interface — a CachedQuery helper or a base repository method — so that replacing the package with a ~60-line in-house trait is a one-file change, not a find-and-replace across the codebase.
3. Prefer explicit rememberAll($ttl) at audited call sites over global config. Global mode is the feature that makes this package attractive and the feature that makes it dangerous; it can be enabled later once we have hit-rate and staleness data.
4. Pin exactly (1.3.0, not ^1.3) and record the pin in the dependency register with an owner and a review date, since no upstream will ever move it.

Compatibility. Two axes to pin ourselves rather than inherit: the package constraint and the framework constraint. Snapshot the lockfile diff at adoption so any transitive movement is visible. If the package publishes config, commit it and diff it on any future change — there will not be one, but the committed artefact is the documentation. Verify PHP 8.0/8.1 explicitly; the package predates 8.2 and will not have been tested against it.

Sequencing.

1. Source review and the consistency-tolerance audit — which reads can tolerate a 60-second-stale answer. This gates everything.
2. Build the abstraction wrapper first, empty, with a passthrough implementation. Prove the call sites work without caching before introducing caching.
3. Pilot on one non-critical, high-read surface in one service, with instrumentation on hit rate, cache size, and database load.
4. Soak for a full release cycle. Watch specifically for user-visible staleness reports and for Redis memory growth.
5. Expand call sites only from the audited list. Never enable global mode as a first step.
6. Hold the wrapper's passthrough mode as the kill switch, and rehearse flipping it.

Operational Impact

Maintenance. The maintenance burden is inverted from a normal dependency: there is no upgrade treadmill because there is no upstream, and instead a permanent, low-grade ownership cost. The code is small and MIT-licensed, so the realistic posture is "adopt as if forked" — we own the source, we vendored or can vendor it, and we carry the responsibility for any framework incompatibility. Budget for a named owner and a scheduled review at the next Laravel major, at which point the expected outcome is replacement, not upgrade. The good news is the exit cost is low; the bad news is that a low exit cost is also an argument for skipping the dependency and writing the trait directly.

Support. Effectively none. No maintainer, no issue triage, no security disclosure channel, no CVE response. For a package that sits between the application and its primary datastore, and whose failure mode includes serving one tenant another tenant's rows, "no security response channel" is the single most important line in this assessment. It is acceptable only where the alternative — an unmitigated latency or load problem — is the larger risk, and only with the tenant-key question answered in writing.

Scaling. Application-layer scaling is unaffected; the constraint is on the cache tier. Per-query keys mean key cardinality scales with query variety, not with data volume, so memory growth is driven by the number of distinct SQL+binding combinations — which is to say, by long-tail filters and pagination. Forecast this against the existing Redis budget before enabling broadly, set an eviction policy deliberately, and expect the eviction policy to interact with TTL expiry to produce the stampede case. The organisational scaling note from the dependency side also applies: every service that adopts this multiplies the eventual replacement work, so centralise the decision in one owner rather than letting teams pin independently.

Failure modes.

• Cross-tenant data leakage — keys not isolating tenants. Mitigation: written confirmation that every tenant-scoped query binds its discriminator; test with two tenants against the same code path.
• Stale reads after writes — TTL is the only invalidation. Mitigation: restrict to audited consistency-tolerant reads; never on authorisation, balances, or workflow state.
• Cache stampede at expiry — synchronised TTL on hot keys. Mitigation: jitter TTLs, or restrict to surfaces where a thundering herd is survivable.
• Silent degradation on store outage — unverified whether it falls back to the database or errors. Mitigation: test it in the pilot; this is a one-line source read but a production incident if assumed wrong.
• Framework lock-in — the package becomes the reason a service cannot move to Laravel 10+. Mitigation: abstraction wrapper plus passthrough kill switch, and a scheduled replacement at the next major.
• Ecosystem rot — no fix arrives for a discovered defect. Mitigation: treat the source as owned; vendor it if adopted.

Ramp-up. Low for engineers — a trait or macro, a config file, a TTL. The real ramp-up cost is on the reviewer and the on-call: someone must own the consistency-tolerance judgement per call site, and someone must be able to explain, during an incident, why a user is seeing yesterday's number. Budget that as design and review time, not implementation time. Realistically a senior engineer-day to audit and pilot, versus roughly the same to write the equivalent internal trait — which is why the recommendation for most teams should be do not adopt; reimplement the pattern internally behind the same API, capturing the ergonomics without inheriting an archived dependency whose failure modes touch tenant isolation. Adopt only where a service is pinned to Laravel 8/9, the latency problem is real and measured, and the tenant-key question has a documented answer.