Ezplatform Http Cache Laravel Package

Technical Evaluation

Architecture Fit

• Purpose Alignment: The ezsystems/ezplatform-http-cache package is designed for HTTP caching in Ibexa DXP (formerly eZ Platform), leveraging Varnish for edge caching. It integrates with Symfony-based applications, making it a strong fit for Laravel applications (via Symfony bridge or custom adapters) requiring HTTP-level caching (e.g., CDN, reverse proxy caching).
• Key Features:
  • Varnish integration (supports Varnish 6/7).
  • Cache invalidation (translation-aware, content publication triggers).
  • Conditional header handling (e.g., Vary, Authorization, Cookie).
  • Edge-side includes (ESI) support for partial caching.
• Laravel Compatibility:
  • Requires Symfony components (e.g., HttpFoundation, HttpKernel), which Laravel already uses.
  • Can be adapted via Symfony Bridge or custom middleware to intercept responses.
  • No native Laravel support, but modular design allows integration.

Integration Feasibility

• Symfony Dependency: Heavy reliance on Symfony’s HttpKernel and EventDispatcher means Laravel integration will require:
  • Middleware adaptation (e.g., wrapping Symfony events in Laravel’s middleware pipeline).
  • Service container bridging (e.g., using Laravel\SymfonyBridge or custom bindings).
• Cache Backend Agnosticism:
  • Primarily designed for Varnish, but core logic (e.g., cache tags, invalidation) can be abstracted for other HTTP caches (e.g., Cloudflare, Fastly).
  • Opportunity: Extend to support Laravel’s cache drivers (Redis, Memcached) for hybrid caching.
• Event-Driven Architecture:
  • Uses Symfony’s kernel.response event to modify responses before caching.
  • Laravel’s events or middleware can mirror this behavior.

Technical Risk

Key Questions

1. Why HTTP Caching?
   • Is the goal reducing origin load, improving TTFB, or CDN integration?
   • Will this replace Laravel’s opcode/cache drivers (e.g., Redis) or complement them?
2. Cache Backend Strategy
   • Is Varnish mandatory, or can we use Cloudflare/Fastly with adapted logic?
3. Invalidation Granularity
   • How will Laravel’s cache tags (e.g., posts:123) map to HTTP cache tags (e.g., Content-Type:123)?
4. Fallback Mechanism
   • What happens during cache misses or Varnish failures? (e.g., graceful degradation)
5. Monitoring & Debugging
   • How will we track cache hits/misses and invalidation events in Laravel’s logging?
6. Team Expertise
   • Does the team have Symfony/Varnish experience, or will this require upskilling?

Integration Approach

Stack Fit

• Laravel + Symfony Bridge:
  • Use symfony/http-kernel to replicate Symfony’s HttpKernelInterface.
  • Leverage Laravel\SymfonyBridge for event dispatching.
• Middleware Pattern:
  • Create a Laravel middleware that:
    1. Wraps the request in a Symfony Request object.
    2. Dispatches kernel.response events.
    3. Applies HTTP cache headers (e.g., X-Ibexa-Cache-Tag).
• Cache Backend Abstraction:
  • Decouple Varnish-specific logic via interfaces (e.g., HttpCacheBackendInterface).
  • Implement adapters for Cloudflare, Fastly, or even Laravel’s cache drivers.

Migration Path

Compatibility

• Laravel Versions:
  • Tested with Laravel 8+ (Symfony 5+ compatibility).
  • May require adapters for older Laravel versions (e.g., 7.x).
• PHP Version:
  • Requires PHP 7.4+ (Ibexa DXP’s minimum).
• Symfony Components:
  • HttpFoundation (v5.4+), HttpKernel (v5.4+), EventDispatcher.
  • Conflict Risk: Minimal if using Laravel’s service container properly.

Sequencing

1. Phase 1: Core Integration
   • Implement Symfony event bridging in Laravel middleware.
   • Test with a static cache backend (e.g., mock Varnish responses).
2. Phase 2: Varnish/HTTP Cache
   • Deploy Varnish/Cloudflare and configure ezplatform-http-cache.
   • Validate Cache-Control, Vary, and Surrogate-Key headers.
3. Phase 3: Invalidation
   • Sync Laravel’s cache:tags with HTTP cache invalidation.
   • Test content updates, user-specific content, and ESI fragments.
4. Phase 4: Monitoring
   • Add cache stats middleware (e.g., X-Cache-Status headers).
   • Integrate with Laravel Horizon for invalidation queueing.

Operational Impact

Maintenance

• Dependency Management:
  • Symfony components will need version pinning to avoid conflicts.
  • Varnish updates may require ezplatform-http-cache version bumps.
• Configuration Drift:
  • Cache rules (TTL, Vary headers) must be documented and version-controlled.
  • Environment-specific configs (e.g., dev/staging/prod Varnish setups).
• Upgrade Path:
  • Follow Ibexa DXP’s release cycle (quarterly major updates).
  • Backward compatibility is a strength, but breaking changes may require migration scripts.

Support

• Debugging Complexity:
  • HTTP cache issues (e.g., stale content, bypasses) require Varnish logs + Laravel logs.
  • Tooling: Use varnishlog, curl -I, and Laravel’s dd() for debugging.
• Vendor Lock-in:
  • Ibexa BUL license may limit support options (GPL is fallback but restrictive).
  • Community support is limited (46 stars, no dependents).
• SLA Considerations:
  • Varnish/Cloudflare SLA may impact uptime (e.g., CDN outages).

Scaling

• Horizontal Scaling:
  • Varnish clusters can scale horizontally; Laravel origin scales independently.
  • ESI includes enable partial caching (reduces origin load).
• Cache Warming:
  • Implement background jobs (e.g