Caching Laravel Package

Technical Evaluation

Architecture Fit

• Misalignment with Laravel’s caching abstractions: The package adheres to Nette’s IStorage interface, which lacks critical Laravel-specific features like cache tags, event-driven invalidation, and PSR-16 compliance (despite PSR-16 adapter added in v3.3.1, it remains untested for Laravel’s Repository contract).
• No Laravel facade/provider integration: Absence of Illuminate\Support\Facades\Cache compatibility or Laravel’s CacheServiceProvider means manual shimming is required, increasing maintenance overhead.
• Inconsistent API design: Laravel’s Repository contract expects methods like get(), put(), tags(), and forever(), while Nette’s Cache class uses load(), save(), and clean(), forcing a custom adapter layer that defeats the package’s "easy-to-use" value proposition.
• No support for Laravel’s optimized drivers: The package lacks native integration with Laravel’s Redis, Memcached, or database cache drivers, requiring reinvention of Laravel’s optimized storage backends.

Integration Feasibility

• High friction for Laravel adoption: The package’s lack of Laravel-specific tooling (e.g., CacheManager, CacheRepository, or CacheTagger) means teams must:
  • Build a custom facade to bridge Nette\Caching\Cache ↔ Illuminate\Contracts\Cache\Repository.
  • Implement tag-based invalidation manually, duplicating Laravel’s Cache::tags() logic.
  • Replicate Laravel’s event system (e.g., CacheStoredEvent) for consistency.
• No dependency injection compatibility: Laravel’s IoC container expects cache drivers to implement Illuminate\Contracts\Cache\Store, while Nette’s IStorage is incompatible, requiring manual binding in Laravel’s service container.
• PSR-16 adapter is insufficient: The v3.3.1 PSR-16 adapter does not address Laravel’s tagging or event requirements, making it a partial solution at best.

Technical Risk

• High risk of technical debt:
  • Custom adapter layer required for Laravel integration introduces maintenance burden and potential bugs (e.g., race conditions in tag invalidation).
  • No Laravel-specific testing: The package’s test suite does not cover Laravel’s use cases, increasing integration risk.
• Legal and compliance risks:
  • NOASSERTION license remains unresolved, posing enterprise adoption barriers.
  • Suspicious release date (2026-05-12) suggests abandonment or bot activity, raising concerns about long-term viability.
• Performance and scalability risks:
  • Nette’s file-based storage (FileStorage) lacks Laravel’s optimized disk caching (e.g., file driver with cache/ directory).
  • No Redis/Memcached optimizations for Laravel’s high-traffic scenarios (e.g., predis or phpredis integration).

Key Questions for TPM

1. Is the package’s "easy-to-use" API worth the Laravel integration overhead?
   • The custom adapter layer may negate the package’s simplicity, making it less maintainable than Laravel’s native cache system.
2. Can we justify the risk of abandoning Laravel’s optimized drivers?
   • Laravel’s Redis, Memcached, and database drivers are battle-tested; reinventing them with Nette’s backends introduces unnecessary complexity.
3. How will we handle cache tags and events?
   • Laravel’s tag-based invalidation and event system are core features—manual implementation will increase bug surface area.
4. Is the NOASSERTION license acceptable for our stack?
   • If the license is unresolved, legal teams may block adoption, especially in regulated industries.
5. What’s the migration path if we adopt this now?
   • Future Laravel upgrades may break our custom adapter, requiring ongoing maintenance.

Integration Approach

Stack Fit

• Poor fit for Laravel’s ecosystem:
  • The package does not align with Laravel’s dependency injection, facade system, or cache driver contracts.
  • No native support for Laravel’s Redis, Memcached, or database caching, forcing reinvention of optimized backends.
• Better suited for Nette or standalone PHP:
  • The package’s strengths (multi-backend support, PSR-16 adapter) are irrelevant to Laravel’s caching needs.
  • No Laravel-specific tooling (e.g., CacheManager, CacheRepository) means manual integration is required.

Migration Path

• Option 1: Abandon Laravel’s Cache System (Not Recommended)

  • Replace Illuminate\Cache\CacheManager with a custom Nette-based adapter.
  • Steps:
    1. Create a Laravel service provider to bind Nette’s Cache to Laravel’s CacheRepository.
    2. Implement a facade (NetteCache::get(), NetteCache::put()) to mimic Laravel’s API.
    3. Manually replicate tag invalidation and event system.
    4. Replace all cache drivers (Redis, Memcached, etc.) with Nette’s backends.
  • Risks:
    • High maintenance burden (custom logic for tags, events, and drivers).
    • Performance degradation (no Laravel-optimized backends).
    • Breaking changes in future Laravel upgrades.

• Option 2: Hybrid Approach (Partial Adoption)

  • Use Nette’s caching only for non-critical, non-tagged caches (e.g., array or file driver).
  • Steps:
    1. Add Nette’s Cache as a secondary cache store (e.g., for template caching).
    2. Avoid tag-based invalidation (use simple load()/save()).
    3. Keep Laravel’s native drivers for critical caches (Redis, database).
  • Risks:
    • Inconsistent caching behavior (mixing Nette and Laravel APIs).
    • No benefit from the package’s "unified API" since Laravel’s system remains dominant.

• Option 3: Reject and Use Laravel’s Native Cache (Recommended)

  • Stick with Laravel’s Illuminate\Cache, which is:
    • Optimized for Laravel’s ecosystem (Redis, Memcached, database drivers).
    • Fully integrated with facades, tags, and events.
    • Actively maintained by the Laravel team.
  • Benefits:
    • Zero integration risk.
    • Leverages Laravel’s optimized backends.
    • No custom adapter maintenance.

Compatibility

• No direct compatibility with Laravel’s:
  • Illuminate\Contracts\Cache\Repository.
  • Illuminate\Cache\CacheManager.
  • Illuminate\Support\Facades\Cache.
• PSR-16 adapter (v3.3.1) is insufficient:
  • PSR-16 lacks tag support, which is core to Laravel’s caching.
  • No Laravel-specific extensions (e.g., Cache::tags()).

Sequencing

If proceeding with Option 1 (Full Replacement):

1. Phase 1: Proof of Concept (2-4 weeks)
   • Build a minimal Nette cache adapter for Laravel.
   • Test with non-tagged caches (e.g., array driver).
2. Phase 2: Tag and Event Implementation (4-6 weeks)
   • Implement tag-based invalidation and event listeners.
   • Test with Laravel’s Cache::tags() and cache events.
3. Phase 3: Driver Replacement (6-8 weeks)
   • Replace Redis/Memcached/database drivers with Nette’s backends.
   • Benchmark performance against Laravel’s native drivers.
4. Phase 4: Full Migration (8+ weeks)
   • Replace all Cache:: usages in the codebase.
   • Deprecate Laravel’s cache system in favor of Nette’s.

Risks at Each Phase:

• Phase 1: High risk of API mismatches (e.g., load() vs. get()).
• Phase 2: High risk of tag invalidation bugs (race conditions, partial clears).
• Phase 3: High risk of performance degradation (Nette’s backends may not match Laravel’s optimizations).
• Phase 4: Breaking changes in future Laravel upgrades may require rework.

Operational Impact

Maintenance

• High maintenance overhead:
  • Custom adapter layer requires ongoing updates to match Laravel’s API changes.
  • No Laravel-specific documentation means debugging is harder.
  • Tag and event logic must be manually maintained, increasing bug surface area.
• Dependency on Nette’s ecosystem:
  • Future Nette updates may break Laravel integration