Laravel Storage Laravel Package

Getting Started

Start by pulling the package in and inspecting what it actually registers, because at zero stars and zero dependents the fastest path to understanding is reading the service provider rather than the README:

composer require ethical-jobs/laravel-storage
php artisan vendor:publish --provider="EthicalJobs\Storage\StorageServiceProvider"

Look at three things first:

1. composer.json in the package — check the Laravel version constraint and whether it leans on illuminate/cache, illuminate/database, or a custom driver contract. That tells you what it is really wrapping.
2. The service provider's register()/boot() — note any singleton bindings, config merges, and auto-discovered aliases.
3. config/storage.php (or whatever gets published) — this is where the backing store, TTLs, and key prefixes live.

The first use case to try is the one the name implies: putting a repository behind a storage/cache layer so repeated reads don't hit the database. In a controller or service, resolve the repository out of the container rather than new-ing it, then call a read method twice and confirm the second call is served from cache (log the query or watch Redis/database cache hits). If that round trip works, you understand the core contract and can build from there.

Implementation Patterns

Repository-per-aggregate with a shared base. The typical shape is a base repository class from the package that you extend per model, overriding the model class, cache key, and TTL. Keep one repository per aggregate root and inject the interface into your services — that keeps the storage layer swappable and testable.

Read-through caching on query methods. The day-to-day value is wrapping find, paginated listings, and count/summary queries so they read-through to the configured store and write back on miss. Put the cache concern in the repository, not the controller, and make sure update/delete in the same repository bust the keys it owns. If the package doesn't do this for you, wire it in boot() via model events:

User::saved(fn ($user) => $repo->forget($user->getKey()));
User::deleted(fn ($user) => $repo->forget($user->getKey()));

Key namespacing. Build cache keys from a stable prefix plus a hash of the query parameters. Include the tenant/account ID if you are multi-tenant, and include a schema or serialization version so a deploy that changes the shape doesn't serve stale structures.

Service-layer injection. Bind repository interfaces to implementations in a dedicated RepositoryServiceProvider, then type-hint the interface in your services and jobs. This makes swapping a storage implementation (array store in tests, Redis in production) a config change rather than a code change.

Use it in queued jobs and console commands too. Because the repository is container-resolved, the same cached reads protect expensive nightly reports and background syncs — not just HTTP requests.

Gotchas and Tips

• Serialization is the sharp edge. Caching Eloquent models or collections across requests means the payload must survive PHP serialization. Prefer caching plain arrays/DTOs or IDs, or confirm the package serializes and rehydrates models correctly for your Laravel version. __PHP_Incomplete_Class and broken relations are the usual symptoms.
• Cache stampede. Popular keys expiring together will hammer the database. Add jitter to TTLs or use a lock (Cache::lock) around cold reads if the package doesn't guard this.
• Invalidation is your job. There is no reliable automatic bust unless the package explicitly hooks model events. Audit every write path — mass updates via query builder, insertOrIgnore, direct DB imports — because those bypass observable events and will leave stale entries.
• Config quirks. Check whether TTL is in seconds or minutes, whether null TTL means "forever" or "no cache," and whether the key prefix is applied at the driver level. Set a distinct prefix per environment so local and CI runs don't share entries.
• Debugging: log cache hits/misses behind a flag; drop to CACHE_STORE=array locally to isolate whether a bug is storage-related. cache:clear only clears the store defined by the package's config key, not every store you have configured.
• Driver portability. Test against the driver you actually deploy (Redis vs database vs file). File and database stores behave differently around tags and atomic locks; if the package advertises tag support, verify it works on your chosen backend before relying on it.
• Extension points: the natural place to add behaviour is a custom driver or a decorating repository that wraps the package's class and adds metrics, logging, or key conventions. Do that rather than editing vendor code.
• Risk note: with zero stars and no dependents, treat the package as internal-org tooling. Read the source before upgrading Laravel majors, pin the version in composer.json, and keep a thin abstraction of your own so you can replace it if it goes unmaintained.