Weave Code
Cache Laravel Package
guzzle/cache
Adds response caching to Guzzle HTTP clients. Store and reuse GET responses to cut latency and API calls, with configurable cache pools, TTLs, and cache strategies. Useful for microservices, third‑party APIs, and rate‑limited endpoints.
[Guzzle 3] [READ-ONLY] Subtree split of the Guzzle\Cache component
Frequently asked questions about Cache
- Can I use guzzle/cache with Laravel’s built-in HTTP client (Guzzle 7+)?
- No, this package is for Guzzle 3 only. You’ll need a compatibility layer or wrapper to adapt it for Guzzle 7, which Laravel uses by default. Alternatively, consider Guzzle 7’s native `CacheMiddleware` or modern PSR-16-compliant packages like `cachet/cache`.
- What Laravel versions support guzzle/cache?
- Laravel 5.5+ *might* work with a wrapper, but the package itself is tied to Guzzle 3. Laravel 8+ uses Guzzle 7, so integration requires manual effort. Test thoroughly with your Laravel version and PHP 7.2+.
- How do I configure cache backends (Redis, filesystem) in guzzle/cache?
- The package supports backends like `FilesystemCache`, `RedisCache`, and `ApcuCache`. Configure them via Guzzle’s client options, e.g., `['cache' => new RedisCache($redisClient, 'prefix')]`. Ensure your cache driver is properly initialized and writable.
- Is guzzle/cache thread-safe for Laravel queues or concurrent requests?
- Thread safety depends on the cache backend. Filesystem and APCu are generally safe for single-process Laravel, but Redis/Memcached require proper connection handling. Test under load if using queues or high concurrency.
- How do I handle cache invalidation or stale data in guzzle/cache?
- The package uses TTL (time-to-live) for invalidation, configurable per cache pool. For dynamic data, set short TTLs or implement custom cache strategies. Note: This package lacks advanced invalidation like tag-based purging found in modern PSR-16 caches.
- What are the performance trade-offs of guzzle/cache vs. Laravel’s Cache facade?
- Guzzle’s caching is HTTP-response specific, reducing redundant API calls directly. Laravel’s Cache facade is broader (e.g., views, sessions) but may add overhead. Benchmark both: guzzle/cache is ideal for API-heavy apps, while Laravel’s cache suits mixed workloads.
- Are there alternatives to guzzle/cache for Laravel + Guzzle 7?
- Yes: Use Guzzle 7’s built-in `CacheMiddleware` with PSR-16 caches (e.g., `symfony/cache`, `cachet/cache`). Laravel packages like `spatie/laravel-guzzle` also integrate caching. These avoid Guzzle 3’s limitations and align with modern Laravel.
- How do I test guzzle/cache in a Laravel project?
- Mock the cache backend (e.g., `MockCacheItemPool`) in PHPUnit tests. Verify responses are cached/reused by checking HTTP call counts. Test edge cases like TTL expiration, failed cache writes, and concurrent requests.
- Will guzzle/cache work with Laravel’s HTTP client in config/http.php?
- No, the package requires direct Guzzle 3 client initialization. For Laravel’s HTTP client, you’d need to replace it with a raw Guzzle 3 client (not recommended) or build a wrapper. Consider migrating to Guzzle 7’s native caching instead.
- Is guzzle/cache actively maintained? Should I use it for production?
- This package is unmaintained and tied to deprecated Guzzle 3. For production, evaluate risks: fork it, use a wrapper, or switch to modern alternatives. Document your decision and monitor for breaking changes in cache backends or Guzzle 3.
Weaver
How can I help you explore Laravel packages today?