Notification Bundle Laravel Package

Getting Started

Before spending time here, confirm the framework: rmzamora/notification-bundle is a Symfony bundle (a fork of sonata-project/notification-bundle), not a Laravel package. It ships no ServiceProvider, no config/*.php publish tag, and no facades. Its dependencies lean on symfony/dependency-injection, symfony/console, and the Sonata admin ecosystem. Wiring it into a Laravel app is not a supported path.

If you still want to evaluate it:

1. Skim the upstream docs first — docs.sonata-project.org/bundles/notification/ — since this fork adds nothing user-facing over upstream and the README of the fork is thin.
2. Read src/Backend/ (the backend contract) and src/Consumer.php. The abstraction you'd be borrowing is NotificationBackendInterface plus the consumer/publisher split.
3. The smallest viable first use case is "publish a JSON payload onto a queue and consume it in a worker loop" — conceptually identical to Queue::push() and php artisan queue:work, which is the point.

Practical recommendation: treat this repo as reference material for the backend abstraction, not as a dependency. Install the native Laravel queue system (config/queue.php, queue:work, Horizon for Redis) instead, and read the Sonata backend implementations only if you're designing a custom publisher abstraction.

Implementation Patterns

If you genuinely need the Sonata-style abstraction (mixed backends: Doctrine ORM, AMQP, Redis, MongoDB) inside a Laravel codebase, the pattern is to port the contract, not the bundle:

• Define a MessageBackend interface mirroring NotificationBackendInterface (send, getIterator, acknowledge, initialize).
• Bind it in a ServiceProvider and resolve backends by name from config/notifications.php — the AbstractBackend/AbstractMessage split maps cleanly to Laravel's Queue driver contract.
• Consumers map to Laravel queue workers: instead of Sonata's Consumer binary, use a Job/Listener pair.

Where the upstream patterns are worth studying:

• Producer/consumer isolation — publisher code never touches a backend connection string; only the backend class does. Reproduce that with Laravel's Queue::connection().
• Message acknowledgement — acknowledge() and getIterator() show how a backend-level ack contract differs from Laravel's ack/fail semantics. Useful if you're writing a custom driver for a broker Laravel doesn't ship with.
• Backend selection via DI — Sonata resolves the backend through the container; in Laravel this becomes a Manager class with extend() calls, which is the idiomatic equivalent.

For a greenfield Laravel feature, skip this entirely: use Illuminate\Contracts\Queue\Factory, ShouldQueue jobs, Queue::fake() in tests, Horizon for Redis ops. That stack already gives you the same backend abstraction this bundle was built for, with first-class Laravel support.

Gotchas and Tips

• Archived and unreferenced. 0 stars, 0 dependents, archived upstream fork. Expect PHP-version drift (the Sonata bundle targets Symfony 2.x/3.x era in many branches) and no security fixes. Do not put it on a production composer.json.
• Framework mismatch. Installing it in Laravel won't auto-register anything; you'd have to manually require the autoloaded classes and instantiate backends yourself. The Consumer command is a Symfony\Component\Console\Command\Command, not a Laravel artisan command.
• Autoload collision risk. Sonata namespaces (Sonata\NotificationBundle\…) collide only with the real Sonata bundle — do not install both.
• Config quirks. The upstream uses Symfony's services.xml/config.yml; there is no .env-driven config. Any Laravel app would need to translate backend DSNs from config/services.php-style arrays into whatever array the backend constructor expects.
• Debugging path. If you fork it, the failure modes are almost always backend connection (uninitialized AbstractBackend) and serialization of AbstractMessage. Log the raw payload — the bundle does no schema validation.
• Better extension point. The sonata.notification.backend service tag is the real extension seam. If you're porting, model this as Laravel's QueueManager::extend('yourbackend', fn() => …) — you get connection pooling, worker lifecycle, and failure handling for free.
• Migration tip. If you inherit a codebase already using this bundle and are moving to Laravel, keep the payload format ({type, body, …}) identical when switching to ShouldQueue jobs so in-flight consumers don't choke during the cutover.