Df Cache Laravel Package

Getting Started

• Know what this is first. dreamfactory/df-cache is not a general-purpose Laravel cache package — it's a DreamFactory Platform 2.0 service module. If you're not already running DreamFactory (or building custom services on top of dreamfactory/df-core), you don't want it; use Laravel's built-in Cache facade instead.
• Install: composer require dreamfactory/df-cache. In a full DreamFactory deployment it's typically pulled in via the platform's composer manifest, so you may not need to add it explicitly.
• Where to look first:
  • composer.json — check the df-core and Laravel version constraints. These determine whether the package will even boot in your app.
  • src/ — expect a service provider extending DreamFactory's base provider plus a handler/controller class that the platform's service manager registers.
  • The service's config block (DreamFactory service config or a config/ file) — this is where the cache store and TTL defaults live, not Laravel's config/cache.php.
• First use case: enable the service in the DreamFactory admin (Services → Create → Cache type), then hit the REST endpoint with your API key to write a key and read it back on a subsequent request. That round-trip confirms the store is wired up and persisting.

Implementation Patterns

• Service registration: DreamFactory auto-discovers service providers listed in the platform's service manifest. If registering manually, add the provider to config/app.php (Laravel 5.x style) and confirm the service type shows up in the admin UI.
• Backend configuration: the store (file, redis, memcached, database) is selected through the DreamFactory service config or the platform .env, not Laravel's config/cache.php defaults. Point it at the same Redis/database you use elsewhere if you want shared cache state between services.
• Consuming from other DreamFactory services: resolve the cache handler through DreamFactory's service container rather than instantiating it. That keeps store configuration in a single place and makes swapping the backend a config change.
• Consuming from a co-hosted Laravel app: don't route through this service. Use Illuminate\Support\Facades\Cache against the same Redis/DB connection — same store, none of the DreamFactory coupling.
• REST workflow: treat the service as a thin CRUD facade over the cache store — get, set (with TTL), delete, possibly flush. Wrap calls in your own client with retry/backoff if the store is remote.
• Testing: mock the handler interface for unit tests; for integration tests, swap the configured store to array so tests don't require Redis.

Gotchas and Tips

• Version pinning is the biggest risk. df-cache tracks a specific df-core and Laravel generation (DreamFactory 2.0 is Laravel 5.x). Mixing it with Laravel 10/11 will fail on framework API changes. Verify constraints before composer require.
• Low maintenance signal. 1 star, 0 dependents — treat it as an internal DreamFactory component, not a community library. Budget time to read the source; don't expect docs or Stack Overflow answers.
• Config lives in DreamFactory's world. Editing config/cache.php won't change behavior unless the handler reads from it. Trace the handler constructor to see where the store is actually configured.
• Flush is dangerous. Any "clear" endpoint will wipe the whole store, which may be shared with sessions or queues. Namespace your keys with a prefix and be very careful exposing flush.
• Auth failures look like cache failures. Endpoints sit behind DreamFactory's API key / role system; a 401/403 is platform auth, not a store problem.
• Debugging: enable DreamFactory's debug/logging and watch the platform log — exceptions inside the cache handler are often swallowed and surfaced as generic 500s.
• Extension point: rather than forking, subclass the handler and register your own service type if you need custom key namespacing or serialization. Keep the fork shallow so platform upgrades don't strand you.
• The pragmatic escape hatch: if you're fighting the package, point your Laravel app at the same Redis instance and use the native cache. You lose the REST facade and gain a supported, documented API.