Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Mongodb Messenger Transport

Mongodb Messenger Transport Laravel Package

facile-it/mongodb-messenger-transport

A Symfony Messenger transport that uses MongoDB as its message queue backend. It lets applications send, store, and consume messages through MongoDB collections, offering an alternative to AMQP, Redis, or Doctrine transports for projects already running MongoDB.

View on GitHub
Deep Wiki
Context7

facile-it/mongodb-messenger-transport provides a MongoDB-backed transport for Symfony Messenger, letting you queue and consume messages without a dedicated broker such as RabbitMQ or Redis. It stores serialized messages in configurable MongoDB collections and integrates with Messenger’s standard send/receive workflow, making MongoDB a practical choice when it is already part of your infrastructure.

  • Drop-in Messenger transport configured through a DSN.
  • Configurable collection, queue name, and redelivery timeout.
  • Compatible with retry and failure transport strategies.
  • Uses existing MongoDB deployments for message persistence.
Frequently asked questions about Mongodb Messenger Transport
Can I use facile-it/mongodb-messenger-transport with Laravel?
Not as a native Laravel queue driver. It is a Symfony Messenger transport that depends on facile-it/mongodb-bundle and Symfony's bundle registration lifecycle, which Laravel does not provide. Using it in Laravel means either running Symfony Messenger alongside Laravel's container or forking the transport logic into a custom Laravel queue connector.
Is this a Laravel queue driver or a Symfony Messenger transport?
It is a Symfony Messenger transport backed by MongoDB collections. It plugs into symfony/messenger as a transport factory and is not built on Laravel's queue API, Horizon, or failed_jobs table. Treat any Laravel framing as custom integration work unless the application already uses Symfony Messenger.
What Laravel versions does mongodb-messenger-transport support?
The package does not declare Laravel version support because it is not a Laravel package. You should instead verify its Symfony, PHP, Doctrine MongoDB ODM, and facile-it/mongodb-bundle constraints in composer.json against your runtime. A standard Laravel app cannot install and auto-wire it as-is.
What are the installation requirements for mongodb-messenger-transport?
You need the mongodb PHP extension, Doctrine MongoDB ODM, facile-it/mongodb-bundle, and a supported Symfony version. The Symfony kernel must register the bundle and configure a MongoDB ODM document manager. Check composer.json for exact Symfony and PHP constraints before planning adoption.
How do I configure MongoDB as a Symfony Messenger transport?
Install facile-it/mongodb-bundle, configure the MongoDB ODM document manager, and register the Messenger transport with its DSN and options according to the package README. Then route specific message classes to that transport in Symfony Messenger configuration. This is Symfony configuration, not Laravel queue.php configuration.
Does it support retries, delays, and failed messages?
The package advertises built-in support for retries, delays, and failed-message handling. Because it is a polling MongoDB transport, you should still validate redelivery behavior, duplicate handling, and dead-letter handling under realistic failure scenarios. Do not assume Laravel Horizon or Laravel failed-job semantics apply.
What delivery semantics should I test before using MongoDB as a queue?
Test atomic message claiming, likely via findOneAndUpdate, plus visibility timeout and redelivery behavior. Validate at-least-once delivery, duplicate processing, dead-letter behavior, and worker crash recovery. Also benchmark polling latency and throughput against your async workload SLOs.
Is mongodb-messenger-transport production-ready given its low adoption?
Adoption signals are weak: roughly 7 stars, 0 dependents, and a single visible release. That suggests a small maintainer surface and little public evidence of production use at scale. MIT licensing lets you fork, but it does not remove the cost of owning a message transport.
How does it compare with Laravel Redis, SQS, or database queues?
Laravel's Redis, SQS, database, and Beanstalkd queue drivers are first-class, documented, and integrated with Horizon and Laravel worker semantics. This package bypasses those Laravel queue features and requires Symfony Messenger. It fits best only when MongoDB is already the system of record and Symfony Messenger is already the message bus.
How can I migrate this Symfony transport idea into a Laravel queue connector?
Fork the claim, release, retry, and failed-message logic into an Illuminate\Queue\Connector plus Job implementation. That preserves MongoDB-as-a-queue without pulling in the Symfony bundle dependency tree. Expect roughly one to two sprints of engineering plus ongoing maintenance, or avoid adoption and use Laravel Redis or SQS instead.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
jinas/dhivatar
store-doc/laravel-storage-driver
plus-it/laravel-translation-manager
diephp/perhaps
diephp/telegraph
osmaviation/spreadsheet
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console
pnscripts/filament-broadquill-lite
pnscripts/laravel-sentfold-lite
vleap/mx-sdk-laravel-internal
twidpay/utils
htetmyathlaing/scout-elasticsearch-driver
artisan-toolbox/front-awesome
ls/client-assistant
users-au/laravel-client
cgv/localized-resource