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

Enqueue Laravel Package

micro-module/enqueue

Lightweight Laravel integration for Enqueue, bridging Laravel's queue system with Enqueue message brokers. Register the service provider, configure a transport, and dispatch or consume messages through a familiar queue API while keeping your code portable across supported backends.

View on GitHub
Deep Wiki
Context7

Getting Started

Since this is a zero-star, pre-1.0 message queue library under the micro-module namespace, the first step is reconnaissance rather than installation, because the README will be your only documentation.

composer require micro-module/enqueue
  1. Read the source before the README. Open src/ and look for a ServiceProvider, a QueueManager, and any Contracts/ directory. In micro-module packages the contract interfaces are where the real design lives — a MessageInterface or ProducerInterface tells you far more than the docs will.
  2. Publish and inspect the config. Check the service provider's boot() for $this->publishes() calls, or look for a config/enqueue.php in the package that you can copy into config/ yourself. Pay attention to default connection strings — they are often hardcoded for local Redis/RabbitMQ and will not match your environment.
  3. Register the provider in bootstrap/providers.php (Laravel 11+) or config/app.php if the package does not use auto-discovery.
  4. First use case — a single fire-and-forget job. Before wiring anything sophisticated, get one message out the door and one consumer receiving it. A minimal round-trip is the only way to validate that your broker, credentials, and the package's serializer all agree.
// somewhere in a controller or command
use MicroModule\Enqueue\Facades\Enqueue;

Enqueue::dispatch(new SendWelcomeEmail($userId));

Then run whatever the package offers for a worker — likely php artisan enqueue:work or a console command registered by the provider. Confirm the command's signature with php artisan list | grep enqueue before reading more source.

Implementation Patterns

Producer/consumer separation. Treat this library the way you treat Illuminate\Queue — dispatch from HTTP/controllers, consume in long-running workers. Do not do the work inline on dispatch; the whole point is decoupling.

// Producer side — thin controller
public function store(StoreOrderRequest $request, Enqueue $queue): Order
{
    $order = Order::create($request->validated());
    $queue->publish('orders.created', new OrderCreated($order->id));
    return $order;
}

Fan-out over topics or queues. Micro-module packages usually model routing explicitly. If the API exposes publish($exchange, $routingKey, $message) or a ConnectionInterface, use one exchange per domain and one queue per consumer concern. This lets you add an inventory consumer later without touching the order code.

Idempotent consumers. Because you are on Redis or RabbitMQ under the hood, at-least-once delivery is the default. Every consumer should be keyed on a message id or business key:

public function handle(OrderCreated $message): void
{
    Cache::lock("order-created:{$message->orderId}", 10)->block(5, function () use ($message) {
        // safe to run twice
    });
}

Wrapping the package behind your own facade. Given zero stars and zero dependents, do not let MicroModule\Enqueue\* types leak into your domain code. Add a one-method MessageBus interface in your app, implement it with the package, and bind it in a service provider. If maintenance stops (and it likely will), you swap one adapter class instead of grepping for hundreds of call sites.

Integration with Laravel's queue interface. If the package exposes a Queue implementation compatible with Illuminate\Contracts\Queue\Queue, you can register it in config/queue.php as a custom driver. That is the highest-leverage integration available — it means ShouldQueue jobs, php artisan queue:work, and Horizon-shaped tooling can all be reused. Check for a Connector or Queue class in src/ before assuming the package has its own worker-only story.

Testing pattern. Provide an in-memory or null transport for tests (check the source for a NullTransport, MemoryTransport, or Fake). If the package offers none, write a RecordingMessageBus test double that implements the same contract, so feature tests do not require a running broker.

Gotchas and Tips

  • Zero stars means zero community support. Every non-obvious behavior is your problem. Budget time to read src/ end-to-end — for a package this size, that is usually under an hour and saves days.
  • Version pinning is non-negotiable. With a single release in October 2024 and no dependents, a future dev-main push can break you silently. Lock to a tag: "micro-module/enqueue": "1.0.*" — or if it is genuinely dev-main only, use a commit hash.
  • Connection configuration is the first failure point. Message queue libraries fail in the same three ways every time: TLS settings, virtual host / prefix mismatches, and the client library version. Verify the underlying client (e.g. php-amqplib, predis, phpredis) is a version compatible with your broker, then verify the config points at the right vhost.
  • Serialization is the most common source of consumer-side bugs. Find whether the package uses serialize(), JSON, or a custom encoder. Custom encoders for PHP objects will break the moment you deploy a class with a changed constructor; prefer plain arrays/JSON payloads from day one.
  • Worker supervision and graceful shutdown. Any consumer command must handle SIGTERM. If the package's worker does not, wrap it in Supervisor with an stopwaitsecs that exceeds your longest job, and do not rely on it exiting cleanly.
  • Debug by inspecting the broker directly, not the package. When a message does not arrive, rabbitmqctl list_queues name messages or redis-cli XLEN / PUBSUB CHANNELS will tell you in seconds whether the producer or consumer is at fault. Do not add logging statements inside vendor/ until you have done this.
  • Extension points. Look for interfaces in src/Contracts/ before forking. If there is a TransportInterface or SerializerInterface, you can build a compatible driver (SQS, database, in-memory) rather than replacing the package. If there is not, the fork is unavoidable — copy it into app/Support/ and treat it as your own code from that point.
  • Watch for the abandoned Laravel package. With 0 dependents and one release, assume maintenance has stopped. Track the repo in your composer.json abandoned audit and have an exit plan: because you wrapped it behind your own MessageBus interface, the plan is a one-file swap to Symfony Messenger or Laravel's native queue.
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.
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
noith/settings
kda/laravel-package
kda/filament-dynamic-navigation
bypersoft/signbox
pairus/product-data
fayne/laravel-filament-cms-core
nodisrupt/laravel-agent
sierratecnologia/media-manager