Push Laravel Package

Technical Evaluation

Architecture Fit

• Pros:

  • Aligns with Laravel’s service-oriented architecture, enabling modular push notification delivery.
  • Supports Google FCM and Mozilla Push (via AggregatePushService), allowing future-proofing for multi-provider needs.
  • Encryption abstraction (Crypt interface) enables custom implementations (e.g., AWS KMS, HashiCorp Vault) if needed.
  • MIT license ensures compatibility with proprietary Laravel projects.

• Cons:

  • Archived status (last release: 2016) raises concerns about deprecated dependencies (e.g., Guzzle v6, PHP 7.0) and security risks (e.g., outdated ECC library).
  • No Laravel-specific optimizations (e.g., no native integration with Laravel’s queue/worker systems or service container).
  • Limited documentation for edge cases (e.g., retry logic, payload validation).

Integration Feasibility

• Laravel Compatibility:
  • Requires PHP 7.0+ (Laravel 5.5+ supports this, but newer versions may need dependency updates).
  • Guzzle v6 is outdated; Laravel’s default HTTP client (Guzzle v7+) would need a wrapper or fork.
  • No native Laravel service provider (would need manual binding in AppServiceProvider).
• Key Dependencies:
  • mdanter/ecc (Elliptic Curve Cryptography) is unmaintained and may fail with modern PHP/OpenSSL.
  • Fallback to spomky-labs/php-aes-gcm is not recommended per the README (performance/security tradeoffs).

Technical Risk

• High:
  • Security: Outdated crypto libraries risk vulnerabilities (e.g., ECC side-channel attacks).
  • Maintenance: No active development means no fixes for PHP 8.x+ incompatibilities (e.g., named arguments, JIT).
  • Functionality Gaps:
    • No built-in batch sending, priority queues, or analytics.
    • No support for Apple Push Notification Service (APNs) or Firebase Cloud Messaging (FCM) v1 API.
  • Performance: Fallback encryption (PHP-native) is slower than ext-crypto/lib-openssl.

Key Questions

1. Is security a critical requirement?
   • If yes, this package is not viable due to outdated crypto dependencies. Consider alternatives like:
     • web-push-php (active, supports FCM/APNs).
     • Laravel’s notifications channel with a custom PushService.
2. Can dependencies be updated?
   • Forking the repo to modernize dependencies (Guzzle v7+, PHP 8.1+) may be necessary but introduces maintenance overhead.
3. Are multi-provider needs confirmed?
   • If only FCM is needed, Laravel’s built-in Notification system with a custom PushChannel may suffice.
4. What’s the failure tolerance?
   • No retry logic or dead-letter queues are built-in; would need custom implementation.

Integration Approach

Stack Fit

• Laravel Ecosystem:

  • Pros:
    • Can be integrated as a custom notification channel (extends Illuminate\Notifications\Notification).
    • Works with Laravel’s queue system (e.g., PushNotification::dispatch($subscription)).
  • Cons:
    • No native Laravel integration (e.g., no PushNotification::route() helper).
    • Manual setup required for service binding, encryption, and error handling.

• Alternative Stacks:

  • Symfony: The cmnty/push-bundle provides better integration but shares the same risks.
  • Standalone PHP: Viable for non-Laravel projects but lacks Laravel’s conveniences.

Migration Path

1. Assessment Phase:
   • Audit dependencies (composer why-not cmnty/push) for conflicts.
   • Test with a staging environment using PHP 7.4+ (closest to Laravel’s LTS).
2. Integration Steps:
   • Option A (Minimal Viable):
     1. Install via Composer (with --ignore-platform-reqs if needed).
     2. Bind services in AppServiceProvider:

        $this->app->singleton(PushServiceRegistry::class, fn() => new PushServiceRegistry());
        $this->app->singleton(Client::class, fn($app) => new Client(
            $app->make(AggregatePushService::class),
            null,
            new Cryptograph(new OpenSSLCrypt()) // Force OpenSSL if available
        ));
        

     3. Create a custom PushNotification class extending Illuminate\Notifications\Notification.
   • Option B (Fork & Modernize):
     1. Fork the repo and update dependencies (Guzzle v7+, PHP 8.1+).
     2. Add Laravel-specific features (e.g., queue jobs, event listeners).
     3. Publish a private package or submit PRs upstream (low likelihood of acceptance).
3. Fallback Plan:
   • Use Laravel’s Notification system with a custom PushChannel and a modern library like web-push-php.

Compatibility

• PHP Versions:
  • Tested: PHP 7.0–7.2 (Laravel 5.5–7.x).
  • Untested: PHP 8.0+ (may require polyfills or forks).
• Laravel Versions:
  • Compatible: Laravel 5.5+ (PHP 7.0+).
  • Unsupported: Laravel 8.x+ (PHP 8.0+) without modifications.
• Dependencies:
  • Critical Conflicts:
    • Guzzle v6 vs. Laravel’s Guzzle v7+.
    • ext-crypto is deprecated in PHP 8.0+ (use openssl extension instead).

Sequencing

1. Phase 1 (Proof of Concept):
   • Implement a single-provider (e.g., FCM) using the package.
   • Validate encryption and payload delivery.
2. Phase 2 (Production Readiness):
   • Add retry logic (e.g., Laravel queues with exponential backoff).
   • Implement monitoring (e.g., track failed pushes in failed_jobs table).
3. Phase 3 (Scaling):
   • Replace with a modern alternative (e.g., web-push-php) if forking isn’t sustainable.

Operational Impact

Maintenance

• Effort:
  • High: Requires manual updates for dependency vulnerabilities (e.g., Guzzle, ECC).
  • Security Patches: None expected; must monitor for PHP/OpenSSL CVEs affecting ext-crypto/openssl.
• Dependencies:
  • mdanter/ecc: No updates since 2017; replace with paragonie/curve25519 if possible.
  • Guzzle v6: End-of-life; migrate to v7+ in a fork.
• Tooling:
  • Static Analysis: Use phpstan to detect deprecated features (e.g., create_function).
  • Testing: Add PHPUnit tests for edge cases (e.g., malformed subscriptions).

Support

• Issues:
  • No community support: GitHub issues are closed; rely on Laravel forums or Stack Overflow.
  • Debugging: Limited logging; may need to extend Client for verbose output.
• SLA:
  • No guarantees: Archived packages imply no bug fixes for Laravel 8.x+ or PHP 8.x.
• Workarounds:
  • Use Laravel’s debugbar to log push attempts.
  • Implement a custom support ticket system for push failures.

Scaling

• Performance:
  • Encryption Bottleneck: Fallback to PHP-native crypto is ~10x slower than openssl.
  • Throughput: No built-in batching; send one push per HTTP request.
• Horizontal Scaling:
  • Stateless: Can scale horizontally, but no connection pooling for push providers.
  • Rate Limits: Must implement exponential backoff for FCM/Mozilla throttling.
• Database:
  • No built-in storage: Subscriptions must be stored manually (e.g., subscriptions table).
  • Cleanup: Add a cron job to purge invalid subscriptions.

Failure Modes