Notifications Laravel Package

Technical Evaluation

Architecture Fit

• Monolithic vs. Modular: The package is tightly coupled with Ibexa DXP, a CMS framework, and assumes integration into a Symfony-based stack. If the target system is a standalone Laravel application (non-Ibexa), architectural alignment requires:
  • Symfony compatibility layer (e.g., Symfony Bridge for Laravel) to abstract dependencies like symfony/notifier, symfony/mailer, and event dispatchers.
  • Custom event listeners/handlers to bridge Ibexa’s notification system with Laravel’s service container and event system.
• Notification Patterns: Supports typed system notifications (e.g., emails, push, SMS) and dynamic templates, which aligns with Laravel’s event-driven architecture but may require custom adapters for Laravel’s Notification facade or third-party services (e.g., Laravel Echo for push notifications).
• Database Schema: Likely relies on Ibexa’s entity-aware storage (e.g., Doctrine ORM). A Laravel TPM must evaluate:
  • Whether to reuse Ibexa’s schema (risk: tight coupling) or map to Laravel’s migrations.
  • Support for soft-deleted notifications (if needed) via Laravel’s SoftDeletes trait.

Integration Feasibility

• Core Dependencies:
  • Symfony 7.4 LTS: Requires Laravel 10+ (PHP 8.3+) due to Symfony’s version constraints. Feasibility: High if using Laravel 10+ with Symfony Bridge.
  • Doctrine ORM: Ibexa uses Doctrine; Laravel’s Eloquent is incompatible without a custom repository layer or Doctrine integration (e.g., fruitcake/laravel-doctrine).
  • Symfony Notifier/Mailer: Must be mocked or replaced with Laravel’s Mail/Notification services.
• API Surface:
  • Service Container: Ibexa uses Symfony’s DI; Laravel’s bindings or macroable services may need to wrap Ibexa’s services.
  • Configuration: Ibexa’s notifier config (YAML/XML) must be converted to Laravel’s .env or config/notifications.php.
• Testing: Limited Behat/unit tests suggest manual integration testing will be required for edge cases.

Technical Risk

Key Questions

1. Is Ibexa DXP a hard dependency, or can notifications be decoupled?
   • If decoupled, what Laravel-native alternatives (e.g., spatie/laravel-notification-channels) could replace Ibexa’s features?
2. What notification channels are required?
   • Email (Laravel Mail), SMS (Twilio), Push (Laravel Echo), or custom channels?
3. How will notifications be triggered?
   • Ibexa’s event-driven model vs. Laravel’s queues/jobs (e.g., Bus or ShouldQueue).
4. Is real-time delivery needed?
   • Ibexa may use WebSockets; Laravel would require Pusher/Ably or Laravel Echo.
5. What’s the data persistence strategy?
   • Ibexa’s Doctrine entities vs. Laravel’s Eloquent models (or hybrid approach).
6. Who owns support?
   • Ibexa’s commercial license may limit community support; internal team must handle troubleshooting.

Integration Approach

Stack Fit

• Laravel Compatibility:
  • PHP 8.3+: Required by Ibexa v5.x (aligns with Laravel 10+).
  • Symfony Dependencies: Must be isolated (e.g., via symfony/console for CLI tools only).
  • Service Container: Use Laravel’s bindings to register Ibexa services:

    $this->app->bind(IbexaNotificationService::class, function ($app) {
        return new IbexaNotificationService(
            $app->make(Notifier::class), // Symfony Notifier
            $app->make(TemplateRenderer::class)
        );
    });
    

• Database:
  • Option 1: Use Doctrine ORM alongside Eloquent (complex, requires fruitcake/laravel-doctrine).
  • Option 2: Map Ibexa’s entities to Eloquent models (recommended for simplicity).
  • Option 3: Hybrid approach (e.g., store notifications in Laravel DB but use Ibexa’s logic for processing).

Migration Path

1. Phase 1: Dependency Isolation
   • Install Ibexa’s package via Composer with --ignore-platform-reqs if needed.
   • Set up Symfony Bridge (symfony/console, symfony/dependency-injection) in config/app.php.
   • Example:

     composer require ibexa/notifications symfony/console symfony/dependency-injection
     

2. Phase 2: Configuration Layer
   • Convert Ibexa’s YAML config to Laravel’s .env:

     IBEXA_NOTIFICATION_DRIVER=mail
     [email protected]
     

   • Create a config file (config/ibexa-notifications.php) to override defaults.
3. Phase 3: Service Integration
   • Register Ibexa’s services in AppServiceProvider:

     public function register()
     {
         $this->app->singleton(Notifier::class, function ($app) {
             return new Notifier([
                 new MailTransport($app['mailer']),
                 new PushTransport($app['pusher']),
             ]);
         });
     }
     

4. Phase 4: Event Listeners
   • Bridge Laravel events to Ibexa’s notification system:

     // Example: Trigger Ibexa notification on Laravel event
     event(new OrderShipped($order));
     app(IbexaNotificationService::class)->send(
         new OrderShippedNotification($order)
     );
     

5. Phase 5: Testing
   • Write Pest/PHPUnit tests for:
     • Notification dispatching.
     • Template rendering.
     • Channel-specific delivery (e.g., email via Laravel Mail).

Compatibility

Sequencing

1. Proof of Concept (PoC)
   • Implement a single notification type (e.g., email) to validate integration.
2. Core Features
   • Add typed notifications (e.g., OrderShippedNotification).
   • Implement dynamic templates.
3. Advanced Features
   • Add push/SMS channels (if needed).
   • Integrate with Laravel Horizon for queue monitoring.
4. Optimization
   • Cache templates (e.g., Laravel View caching).
   • Add rate limiting for notification spikes.

Operational Impact

Maintenance

• Dependency Updates:
  • Ibexa’s Symfony 7.4 dependency may require Laravel 10+ updates.
  • License renewals: Ibexa BUL requires annual subscription for commercial use.
• Custom Code:
  • Adapters/wrappers for Ibexa services will need updates if Ibexa releases BC breaks