Weave Code
Caching Laravel Package
nette/caching
Nette Caching is a fast, flexible PHP caching library with memory, file, and distributed backends. It supports expiration, tags, namespaces, and dependency-based invalidation, making it easy to speed up PHP applications.
Nette Caching is a lightweight, dependency-free PHP library providing a unified API for caching data in memory, files, SQLite, Memcached, or Redis. It offers key-based storage with automatic expiration, namespacing, and lazy loading, making it easy to speed up expensive operations without tying your code to a specific backend.
- Unified storage API across files, memory, database, and distributed backends
- Automatic expiration with TTL, sliding, and absolute time support
- Namespaced caches to isolate and invalidate groups of entries
- Lazy loading via callbacks with built-in stampede protection
- PSR-6 / PSR-16 compatible adapters for ecosystem interoperability
Frequently asked questions about Caching
- Can I use nette/caching with Laravel out of the box?
- No. nette/caching ships no service provider, facade, or config file, so there is nothing for Laravel to auto-discover. Integration needs a thin adapter you write and own: either implement Nette\Caching\Storage on top of a Laravel cache store, or register a custom Laravel cache driver that wraps a Nette Storage. Composer and namespace coexistence is clean because everything lives under Nette\Caching.
- Does nette/caching support Redis?
- No. The package ships FileStorage, MemcachedStorage, SQLiteStorage and DevNullStorage, but no Redis backend, despite some third-party descriptions claiming multi-backend Redis support. On a Redis-standardized Laravel estate this is the biggest integration gap, and adding it means implementing your own Storage and Journal. Check the changelog for the exact storage set in your pinned version, since Memcached handling changed in v3.0.0.
- What PHP version does nette/caching require?
- nette/caching v3.4.0 requires PHP 8.1 or newer, which lines up with Laravel 10 and later. The package is framework-agnostic, so there is no Laravel version constraint and Laravel 11 or 12 on PHP 8.1 through 8.5 works fine. Older PHP 7 projects would have to pin an older release.
- How does dependency-based invalidation work in nette/caching?
- You call Cache::load($key, $callback, $dependencies), where dependencies can be file mtimes, tags, callbacks, or constants, and the entry is invalidated whenever one of them changes. Tracking those relationships requires a Journal, and the only shipped implementation is SQLiteJournal, which needs pdo_sqlite and a writable local file. That dependency graph is the feature Laravel's Cache::tags() cannot fully express, but it also ties invalidation to a single node.
- Why is the SQLite journal a problem for horizontally scaled Laravel apps?
- Because the journal is a local SQLite file, dependency and tag invalidation only propagates on the node that wrote it. In a multi-pod or autoscaling fleet, other instances keep serving stale entries until they expire on their own. Fixing this means designing a shared Journal on Redis or the database yourself, which is an architecture-level gap rather than a patch. Single-node or file-based workloads are unaffected.
- Does nette/caching protect against cache stampede?
- Only partially. capture() and atomic file writes stop readers from seeing half-written fragments, and sliding expiration keeps hot entries alive longer. But there is no cross-process mutex comparable to Laravel's Cache::lock() combined with Cache::remember(), so a cold hot key can still trigger a thundering herd. Pair it with Laravel locks if stampede protection matters for your traffic.
- Does nette/caching implement PSR-6 and PSR-16?
- Yes. It provides PSR-6 and PSR-16 adapters, with the PSR-16 adapter available since v3.3.1. That gives you a legitimate interop boundary when consuming the library from code that expects a standard cache interface. Note that PSR-16 is a key-value-only surface, so Nette-specific features such as tags and dependency invalidation are not exposed through it.
- Is nette/caching stable across minor versions, and should I pin it?
- Mostly stable, but the changelog shows backwards-compatibility breaks in minor releases: v3.3.0 changed CacheExtension paths, v3.1.0 renamed start() to capture(), and v3.0.0 removed Memcached support. Install with composer require nette/caching and pin an exact version such as v3.4.x instead of relying on a caret range. Read the changelog before every bump and budget a little maintenance time per upgrade.
- What license is nette/caching released under?
- Composer metadata reports NOASSERTION, meaning the license could not be detected automatically. Nette libraries are normally BSD-3-Clause, but that has to be confirmed with the maintainers or your legal team before you ship a dependency on it. Do not assume the license just because sibling Nette packages use a permissive one.
- What does nette/caching give me that Laravel's Cache does not?
- Three things stand out: dependency-graph invalidation through Cache::load() with file, tag, callback and constant dependencies; capture() for atomic fragment caching; and a clean Storage seam plus a PSR-16 adapter. Laravel's Illuminate\Cache already covers stores, Cache::remember, tags, atomic locks and cache events, so the overlap is large. Adopt nette/caching only for the specific workloads that need those extra semantics, otherwise you end up maintaining two cache abstractions in one codebase.
Weaver
How can I help you explore Laravel packages today?