Http Cache Laravel Package

Technical Evaluation

Architecture Fit

• Core Use Case Alignment: The ibexa/http-cache package is designed for HTTP-level caching (primarily Varnish integration) within the Ibexa DXP ecosystem, leveraging Symfony’s HTTP cache layer. For a Laravel-based application, this package introduces Symfony-specific abstractions (e.g., HttpCache, Varnish, Purger) that may require adaptation to Laravel’s ecosystem (e.g., Symfony Bridge, PSR-15 middleware).
• Caching Granularity: Supports translation-aware invalidation, tag-based purging, and Varnish 6/7 integration, which are valuable for multi-language, high-traffic Laravel apps (e.g., e-commerce, CMS).
• Middleware-First Approach: Relies on Symfony’s HttpCache middleware, which can be ported to Laravel via middleware wrappers (e.g., Illuminate\Pipeline).

Integration Feasibility

• Symfony Dependency: Requires Symfony 7.4+ (due to v5.x upgrades), introducing compatibility risks with Laravel’s default stack (e.g., Symfony components like HttpFoundation, Cache). Mitigation: Use Laravel’s Symfony Bridge (symfony/http-foundation, symfony/cache) or custom adapters.
• Varnish Configuration: Provides pre-built VCL templates (Varnish 6/7), but Laravel’s reverse proxy setup (e.g., Nginx, Apache) may need custom VCL adjustments.
• Cache Invalidation: Supports tag-based invalidation (e.g., ezpublish:content:update), which can be mapped to Laravel’s cache tags or custom event listeners.

Technical Risk

Key Questions

1. Symfony Compatibility:

   • Can Laravel’s middleware pipeline fully replace Symfony’s HttpCache middleware without performance loss?
   • Are there alternative Laravel packages (e.g., spatie/laravel-cache-control) that offer similar functionality with lower risk?

2. Varnish Strategy:

   • Should Varnish be managed via Laravel middleware (e.g., VarnishPurger) or externally configured (e.g., Ansible/Envoyer)?
   • How will Laravel’s route caching (e.g., php artisan route:cache) interact with Varnish tags?

3. Cache Invalidation:

   • How will Laravel’s event system (e.g., ModelObserver) trigger Symfony-style cache invalidation?
   • Can tag-based invalidation be extended to database-driven caches (e.g., Redis, DynamoDB)?

4. Performance Impact:

   • What are the latency implications of Symfony’s HttpCache vs. Laravel’s native caching?
   • Should edge caching (e.g., Cloudflare) be prioritized over Varnish for Laravel?

5. Licensing:

   • Does the dual GPL/Ibexa BUL license impose restrictions on commercial Laravel projects?
   • Are there fully open-source alternatives (e.g., spatie/laravel-cache-control) that avoid proprietary licensing?

Integration Approach

Stack Fit

• Laravel Compatibility:
  • Symfony Components: Leverage spatie/laravel-symfony-support to integrate HttpFoundation, Cache, and HttpClient.
  • Middleware: Port Symfony’s HttpCache to Laravel middleware using Closure-based pipelines.
  • Routing: Use Illuminate\Routing\Middleware to intercept requests/responses for cache logic.
• Varnish Integration:
  • Option 1 (Middleware-Driven): Extend Varnish class to work with Laravel’s Request/Response objects.
  • Option 2 (External VCL): Deploy Varnish separately and use Purger middleware to invalidate tags via HTTP calls.
• Cache Backend:
  • Supported: Redis, Memcached, File (via Symfony’s Cache component).
  • Unsupported: Laravel’s array driver (requires Symfony’s ArrayAdapter).

Migration Path

1. Phase 1: Dependency Setup

   • Add Symfony components via Composer:

     composer require symfony/http-foundation symfony/cache symfony/http-client
     

   • Install Laravel Symfony Bridge:

     composer require spatie/laravel-symfony-support
     

2. Phase 2: Core Integration

   • Create a Laravel-compatible HttpCache middleware:

     // app/Http/Middleware/HttpCache.php
     use Symfony\Component\HttpFoundation\Request;
     use Symfony\Component\HttpFoundation\Response;
     use Symfony\Component\HttpKernel\HttpCache\HttpCache;
     
     class HttpCacheMiddleware
     {
         public function handle(Request $request, Closure $next): Response
         {
             $symfonyRequest = new SymfonyRequest($request);
             $symfonyResponse = $next($symfonyRequest);
             $laravelResponse = new SymfonyResponse($symfonyResponse);
     
             return $laravelResponse;
         }
     }
     

   • Register middleware in app/Http/Kernel.php:

     protected $middlewareGroups = [
         'web' => [
             \App\Http\Middleware\HttpCache::class,
             // ...
         ],
     ];
     

3. Phase 3: Varnish Configuration

   • Option A (Middleware): Extend ibexa/http-cache/src/Varnish to work with Laravel’s Request:

     // app/Services/VarnishPurger.php
     use Ibexa\HttpCache\Varnish;
     
     class VarnishPurger extends Varnish
     {
         public function purgeTags(array $tags): void
         {
             // Adapt to Laravel's HTTP client
             Http::post('http://varnish/purge', ['tags' => $tags]);
         }
     }
     

   • Option B (External VCL): Deploy Varnish with Ibexa’s VCL templates and use Laravel’s Http client to purge:

     Http::post('http://varnish/purge', ['url' => '/path/to/invalidate']);
     

4. Phase 4: Cache Invalidation

   • Hook into Laravel events (e.g., eloquent.updated) to trigger Symfony-style invalidation:

     // app/Providers/EventServiceProvider.php
     public function boot(): void
     {
         Model::updated(function ($model) {
             app(VarnishPurger::class)->purgeTags(['content:'.$model->id]);
         });
     }
     

Compatibility

Sequencing

1. Start with a Proof of Concept (PoC):
   • Implement basic cache middleware without Varnish.
   • Test with Redis backend and tag-based invalidation.
2. Add Varnish Integration:
   • Choose middleware-driven or external VCL approach.
   • Validate purging logic with Laravel’s HTTP tests.
3. Optimize Performance: