Memoize Laravel Package

Product Decisions This Supports

• Performance roadmap prioritization. Memoization is a cheap, request-scoped optimization that reduces repeated expensive work (DB queries, API calls, heavy computations) without new infrastructure. It supports decisions like "can we hit our p95 latency target this quarter without adding a cache tier?"
• Build vs. buy vs. use-native. This package is one option in a crowded space. The real decision is usually which memoization approach to standardize on: this package, spatie/once, or Laravel 11+'s native once() helper. That's a strategic decision about dependency surface area, not just a code-level choice.
• Feature-level use cases worth scoping:
  • Expensive computed attributes/properties on domain objects (e.g., pricing, eligibility, aggregates) accessed multiple times per request.
  • Repeated policy/authorization checks and permission resolution within a single request.
  • Config/feature-flag resolution called from many layers.
  • Reporting or dashboard endpoints that recompute the same figures across a response graph.
• Standardization decision. Whether to adopt a house convention for request-scoped caching versus ad-hoc static properties and hand-rolled arrays — a maintainability and code-review-quality decision.
• Risk posture on dependencies. With effectively zero adoption signals (no stars, no dependents, score 0), this is a "evaluate, don't default" decision — it argues for a time-boxed spike rather than a platform commitment.

When to Consider This Package

Consider it when:

• You're on PHP 8+ and want per-object or per-class in-memory caching with minimal ceremony and no external cache dependency.
• Your hot paths are dominated by repeated identical computations within a single request, not cross-request cache misses.
• You want zero operational overhead — no Redis/Memcached, no cache invalidation strategy, no TTL tuning.
• Your team is small and would benefit from a declarative convention over hand-written private ?array $cache boilerplate.
• You're willing to vendor-review or fork a low-traffic package and pin it explicitly.

Look elsewhere when:

• You need caching across requests or users. This is in-memory and request-scoped; Redis or Laravel's cache facade is the right tool.
• You're on Laravel 11+. The native once() helper covers the dominant use case with framework support and zero third-party risk — strongly prefer it unless this package offers something once() doesn't.
• You need TTLs, invalidation, or cache tagging. Memoization is intentionally dumb; if you need lifecycle control, use a real cache.
• You run Octane, long-lived workers, or queue daemons. Class-level/static memoization risks stale data and unbounded memory growth across requests in a persistent process. This needs explicit engineering validation before adoption.
• Dependency hygiene matters more than convenience. Zero stars, zero dependents, and a zero score mean no community vetting, no security review trail, and a real bus-factor risk. If your org requires SOC2/audit-friendly dependencies, this likely fails procurement without an internal review.
• You need observability. There's no built-in hit/miss instrumentation; you'd be adding it yourself.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, low-cost performance lever, not a platform investment. It lets engineers avoid recomputing the same expensive values multiple times within a single request — a common, invisible source of latency and database load. The upside is faster pages and fewer redundant queries at essentially zero infrastructure cost. The caveat is maturity: the package has negligible community adoption, so we should treat it as an evaluated tactic rather than a standard, and we may get the same benefit from Laravel's built-in once() helper with no third-party risk.

For engineering (summary): Object- and class-level in-memory memoization for PHP. It solves a real, narrow problem — repeated identical computation within a request — with no external dependencies. Before adopting: (1) confirm Laravel 11's once() doesn't already cover it; (2) audit the package source and pin the version; (3) explicitly test behavior under Octane/queue workers for stale state and memory growth; (4) agree on where memoization is allowed, since it's easy to introduce subtle staleness bugs; (5) add hit/miss instrumentation if we care about measuring the win. Recommendation: time-boxed spike on one hot path, measure query count and p95 latency, then decide between this, spatie/once, or native once().