- How do I install SmartCache in a Laravel application?
- Install it with Composer using composer require iazaran/smart-cache. No configuration publishing is required to get started because SmartCache reuses your existing Laravel cache driver and ships with documented defaults. Enabling ext-zlib is recommended so gzip compression is available for large payloads.
- Which cache drivers does SmartCache support?
- SmartCache supports Redis, File, Database, Memcached, and Array stores. It adds driver-safe chunking, so oversized values are split in a way the underlying driver can handle. Because it decorates Laravel's cache repository rather than replacing the driver, you keep using your normal cache configuration.
- Which Laravel and PHP versions are supported by iazaran/smart-cache?
- The package tests against Laravel 8 through 13 and PHP 8.1 through 8.5. Older framework or PHP versions may still work but do not extend that dependency's upstream security lifetime. For new or enterprise projects, target Laravel 11–13 on PHP 8.2 or newer.
- Can I replace Laravel's Cache facade with SmartCache without rewriting my code?
- In most cases yes, because SmartCache implements Illuminate\Contracts\Cache\Repository, which extends PSR-16, so typical get, put, remember, and forget calls migrate with an import change. However, it is not a fully transparent swap: adoption is per call site via the facade import, and cache-clearing semantics in SmartCache 1.x are intentionally explicit rather than identical to Laravel's default flush behavior. Teams should review flush usage before standardizing on it.
- How does SmartCache handle large cache payloads?
- It applies optimization strategies such as automatic compression, driver-safe chunking, write deduplication, and self-healing recovery when values are large. Chunking splits oversized entries so they fit within driver limits, while compression reduces payload size when ext-zlib is available. Small-value caches see little benefit and mostly pay the metadata overhead, so it is best applied where large payloads are the actual pain point.
- Do I need to audit cache keys before upgrading from an earlier 1.x release to 1.15.0?
- Yes. The 1.15.0 release bundles encryption, namespace, and Redis scan defect fixes, and some of these can change the effective key prefix or ciphertext format. Upgrading without an audit can leave pre-1.15 entries unreadable or unreachable, which produces cold reads and orphaned keys consuming memory such as Redis maxmemory. None of this is a semver breaking change, but it is behavior-changing at the data layer, so plan a key-format check before rollout.
- What is the difference between rememberWithLock, rememberWithStampedeProtection, and throttle in SmartCache?
- All three address overlapping single-flight and stampede scenarios, with rememberWithLock added as a first-class primitive in 1.15.0 alongside the previously documented options. Because the outcomes overlap, teams should pick one deliberately rather than mixing them inconsistently across the codebase. These paths require a store backed by a LockProvider, and lock TTLs should be sized against your slowest cache regeneration time.
- How does clearing the cache work in SmartCache?
- Cache-clearing in SmartCache 1.x is intentionally explicit, so flush behavior is not a silent drop-in for every Laravel default. The Redis scan defect fix may change how pattern-based flushes are executed, but it does not change what flush() clears. Review any code that relies on wildcard or pattern flushing and verify the semantics against your installed version.
- Can SmartCache be used for rate limiting or atomic counters with increment and decrement?
- Be cautious. Wrapping atomic counter operations in compression, deduplication, and metadata layers is a correctness hazard for rate limiters, and increment/decrement parity in SmartCache is not documented as verified. For strict atomic counters, use the underlying Laravel store directly through the repository() or store() escape hatches. Reserve SmartCache for payload optimization where byte size, not atomicity, is the concern.
- Is iazaran/smart-cache actively maintained and safe for production?
- It is a single-maintainer package with roughly 216 GitHub stars and no dependents, so the bus factor is the main risk. The countervailing signal is steady releases with substantive work, including 1.15.0's defect fixes, which makes abandonment less likely than the star count alone suggests. Escape hatches such as repository() and store() let you fall back to native Laravel caching, and you should monitor overhead from metadata keys, chunk keys, and write deduplication in production.