- What is Grafite Cache and when should I use it instead of Redis or the file cache?
- Grafite Cache is a Laravel package that provides an SQLite-backed cache store behind Laravel's existing Cache facade and Repository contract. It fits single-node deployments without Redis, such as shared hosting, small internal apps, or CI setups that need a shared cache across processes. It is not a good fit for high write throughput, multi-node clustering, or workloads needing sub-millisecond reads. If Redis is already available, this package offers little advantage over the standard drivers.
- How do I install and configure grafite/cache in a Laravel application?
- Install it with Composer, register the package's service provider, add a store entry to config/cache.php, and point CACHE_DRIVER at that store. The hard requirements are the pdo_sqlite PHP extension and a writable database path. Check the package documentation for the exact provider class and configuration keys, since the provided overview does not list them.
- Which Laravel and PHP versions does grafite/cache support?
- The provided evaluation does not state supported Laravel or PHP versions, so inspect composer.json's illuminate/* constraints before adopting. If the package pins to a Laravel major you have passed or are approaching, it becomes an upgrade blocker. It also has 0 stars and 0 dependents, which means no community validation and no observable maintenance cadence. Test it on your target Laravel version in a branch first.
- Does grafite/cache implement the full Laravel Cache Store contract, including increment, decrement, and locks?
- The evaluation flags contract completeness as something to verify rather than a confirmed feature. Check that the store implements the full Illuminate\Contracts\Cache\Store surface: get, put, increment, decrement, forget, flush, and forever. If your application uses Cache::lock(), also confirm LockProvider support. A cache driver sits on every request path, so a missing method can degrade the whole app.
- How is the SQLite cache table created, and do I need to run a migration?
- The schema lifecycle is the biggest unknown: the table may be created automatically, through a publishable migration, or manually. Check the package source and README before wiring it into config/cache.php, and make sure the table exists before the first cache read. Without a pruning path, the SQLite table grows unbounded and read latency degrades over time.
- How do I prune expired entries from the Grafite Cache SQLite table?
- The provided evaluation does not confirm a documented prune command or expiry sweep, so determine whether expiry is filtered lazily on read or handled in the background. If there is no built-in pruning mechanism, add a scheduled cleanup job or you will see table growth and slower reads. Verify this in the package docs or source before committing to it in production.
- Is grafite/cache safe for concurrent writes and multiple queue workers?
- SQLite serializes writes, so concurrent requests and queue workers can hit database is locked errors under load. Check whether the package sets busy_timeout, enables WAL mode, or retries on lock contention. For high write throughput or multi-node deployments, use Redis or another service-backed cache instead.
- Does grafite/cache support cache tags and atomic locks?
- Tag support is not confirmed in the provided evaluation, and Laravel's tag semantics silently require a tag-capable store. If your code calls Cache::tags(), test that behavior explicitly rather than assuming it works. Similarly, confirm LockProvider support if you rely on Cache::lock().
- What are the extra features in grafite/cache beyond a standard cache driver?
- The overview mentions some extra features but does not enumerate them, so read the README and source to see what they are and whether they couple you to other Grafite packages. Keep adoption scoped to a replaceable driver behind Laravel's Cache facade rather than a platform commitment. If the extras add dependencies you do not need, the plain Laravel file or database driver may be simpler.
- How do I test and roll back a switch to grafite/cache in production?
- Migration is config-only because everything routes through the Cache facade: add the store, flip CACHE_DRIVER, warm the cache, and roll back by flipping the driver back. The real work is data lifecycle: put the SQLite file outside the deploy artifact and outside any ephemeral filesystem, then set permissions, backup, and ignore rules. Test on staging with representative write volume before switching production traffic.