Fos Http Cache Cloudfront Laravel Package

Technical Evaluation

Architecture Fit

• Purpose Alignment: The package is a CloudFront-specific implementation of FOSHttpCache, enabling edge caching for Laravel applications. It fits well in architectures where:
  • CloudFront is the primary CDN for static/dynamic content delivery.
  • FOSHttpCache is already used for HTTP-level caching (e.g., Symfony-based Laravel apps).
  • Cache invalidation is manual or scripted today, and automation is desired.
• Design Philosophy:
  • Proxy Pattern: Extends FOSHttpCache’s proxy interface (purge(), flush()) with CloudFront-specific logic, reducing boilerplate for AWS API calls.
  • AWS SDK Abstraction: Uses async-aws/cloudfront to handle low-level CloudFront API interactions (e.g., invalidations, warmup).
  • Laravel Agnostic: Designed for PHP/Symfony, not Laravel-native (e.g., no service providers, facades, or queue jobs).
• Key Strengths:
  • Decoupled from Laravel: Can be used in non-Laravel PHP apps if FOSHttpCache is present.
  • Async Support: Built on AWS SDK v3’s async client for non-blocking requests.
  • Caller Reference Handling: Prevents duplicate invalidation requests via configurable generators.
• Key Weaknesses:
  • No Laravel Integration: Requires manual setup (e.g., binding to Laravel’s container, integrating with cache drivers).
  • AWS Dependency: Tight coupling to CloudFront and AWS SDK v3 may conflict with existing Laravel AWS integrations.
  • Limited Observability: No built-in logging or monitoring for invalidation failures.

Integration Feasibility

• Core Features Supported:
  • Cache Invalidation: Supports both single-path (/homepage) and wildcard (/assets/*) purges.
  • Batch Invalidation: Accumulates purges and flushes them in a single API call (efficient for CloudFront).
  • Cache Warmup: Implicitly supported via purge() (CloudFront pre-loads URLs on invalidation).
  • TTL Respect: Relies on CloudFront’s Cache-Control settings (configured separately).
• Gaps:
  • No Laravel Cache Driver Integration: Cannot directly replace Laravel’s cache() facade or Cache tagging.
  • No Event Listeners: Requires manual triggers (e.g., after model updates) for invalidation.
  • No Queue Support: Invalidation is synchronous; no Laravel queue integration for async processing.
• Dependencies:
  • Hard Dependencies:
    • async-aws/cloudfront (AWS SDK v3).
    • symfony/http-cache (for FOSHttpCache compatibility).
  • Soft Dependencies:
    • aws/aws-sdk-php (if using v2; avoid due to conflicts).
    • Laravel’s cache facade (for hybrid caching strategies).

Technical Risk

Key Questions

1. AWS Infrastructure:
   • Are CloudFront invalidation permissions (cloudfront:CreateInvalidation) granted to the Laravel app’s IAM role?
   • Does the CloudFront distribution use origin groups or lambda@edge, which might complicate cache invalidation?
2. Caching Strategy:
   • Should this replace Laravel’s file/redis cache drivers or act as a secondary cache layer?
   • How will Cache-Control headers be synchronized between Laravel and CloudFront?
3. Performance:
   • What is the expected cache hit ratio? Will CloudFront’s default TTL (24h) conflict with business needs?
   • Are there plans to implement cache tagging (e.g., purge by tag) for dynamic content (e.g., user-specific pages)?
4. Operational Impact:
   • How will invalidation failures be monitored (e.g., AWS CloudTrail vs. Laravel logs)?
   • What fallback mechanism exists if CloudFront invalidation fails (e.g., Redis purge)?
5. Laravel-Specific:
   • Should invalidations be triggered by model events (e.g., eloquent.updated) or custom commands?
   • Will this integrate with Laravel’s queue system for async invalidations?

Integration Approach

Stack Fit

• Ideal Use Cases:
  • Laravel + CloudFront: Apps using CloudFront for CDN and FOSHttpCache for HTTP caching.
  • Hybrid Caching: Systems with Redis/Memcached as primary cache and CloudFront as edge cache.
  • Legacy Migration: Replacing custom CloudFront invalidation scripts with a managed solution.
• Tech Stack Compatibility:

  Component	Compatibility
  Laravel 9+/PHP 8.1+	✅ Full support (Symfony HTTP Cache components).
  AWS CloudFront	✅ Required (package is CloudFront-specific).
  FOSHttpCache	✅ Direct extension (assumes existing FOSHttpCache setup).
  Redis/Memcached	⚠️ Partial (can complement but not replace).
  Guzzle/AWS SDK v2	❌ Conflicts (use async-aws/cloudfront instead).
  Laravel Queues	❌ No native support (requires custom integration).

• Anti-Patterns:
  • Overkill for Static Assets: If only serving static files, use CloudFront’s built-in cache behaviors.
  • No CloudFront: Avoid if using Fastly, Cloudflare, or self-hosted caches.
  • Real-Time Data: Not suitable for apps requiring sub-second cache invalidation (e.g., financial dashboards).

Migration Path

1. Phase 1: Assessment (1-2 weeks)

   • Audit existing cache invalidation logic (e.g., cron jobs, manual AWS CLI calls).
   • Verify CloudFront distribution settings:
     • DefaultCacheBehavior (e.g., ForwardedValues, TTL).
     • Origin (e.g., S3, ALB, or custom origin).
   • Check IAM permissions for the Laravel app’s AWS role.

2. Phase 2: PoC (1 week)

   • Install the package in a staging environment:

     composer require jean-beru/fos-http-cache-cloudfront async-aws/cloudfront
     

   • Implement a minimal proxy setup:

     // config/cloudfront.php
     'distribution_id' => env('CLOUDFRONT_DISTRIBUTION_ID'),
     'region'          => env('AWS_REGION'),
     

     // app/Providers/AppServiceProvider.php
     public function boot()
     {
         $this->app->singleton('cloudfront.proxy', function ($app) {
             return new \JeanBeru\HttpCacheCloudFront\Proxy\CloudFront(
                 new \Aws\CloudFront\CloudFrontClient($app['config']['cloudfront']),
                 ['distribution_id' => $app['config']['cloudfront.distribution_id']]
             );
         });
     }
     

   • Test invalidation:

     $proxy = app('cloudfront.proxy');
     $proxy->purge('/homepage')->purge('/assets/*')->flush();
     

3. Phase 3: Laravel Integration (1-2 weeks)

   • Option A: Cache Facade Extension (Recommended): Extend Laravel’s Cache facade to delegate invalidations:

     // app/Extensions/CacheExtension.php
     public function cloudfrontPurge($path)
     {
         return app('cloudfront.proxy')->purge($path);
     }
     

     Register via Facade::extend().
   • Option B: Artisan Command: Create a command for manual invalidations:

     php artisan cache:purge /path/to/invalidate
     

   • Option C: Event Listeners: Trigger invalidations on Eloquent events:

     // app/Listeners/PurgeCacheOnUpdate.php
     public function handle($event)
     {
         app('cloudfront.proxy