Laravel Mqtt Laravel Package

Product Decisions This Supports

• Feature feasibility for device/IoT telemetry: lets a Laravel app publish commands to and subscribe to events from an MQTT broker (Mosquitto, EMQX, HiveMQ, AWS IoT Core) without building a protocol client. This directly informs whether "connected device" or "sensor data" features can ship on the existing PHP stack instead of forcing a separate Node/Go/Python service.
• Request-path performance is no longer a blocker for publish-heavy features (new in v3.3.0): Mqtt::queue() moves publishing onto the Laravel queue, so a user action that fans out device commands or telemetry no longer pays broker round-trip latency inside the HTTP response. This shifts the question from "can we afford to publish synchronously?" to "what queue capacity and worker pool do we need?" — a sizing decision, not an architecture one.
• Build vs. buy vs. glue: the package is a thin wrapper over an MQTT client, so the real decision is about the broker (managed vs. self-hosted) and the integration layer (this package vs. writing a small adapter). Treat the package as replaceable glue, not as architecture. The new async path slightly raises exit cost — queued publish semantics differ between libraries — so the adapter abstraction matters more, not less.
• Roadmap sequencing: MQTT is a good fit for server-to-server and backend-to-device messaging (commands, telemetry ingestion, offline-tolerant delivery with QoS, retained state). It is a poor fit for browser real-time UX — for that, keep Laravel Reverb/Pusher/Soketi on the roadmap and use MQTT only as the backend hop.
• Use cases worth prototyping: hardware command dispatch (locks, dispensers, kiosks, POS terminals), fleet/asset status dashboards, low-bandwidth or intermittent-connectivity sites, ingest pipelines where per-message overhead matters, cross-service event fan-out where Redis pub/sub is too ephemeral, and — now practical — bursty command fan-out from user-facing endpoints (e.g. "unlock all lockers at this site") where the request must return fast.
• Delivery guarantees become a product conversation, not a library one: with queued publishing, delivery is eventually-consistent by default. A command can be accepted into the queue and the user told "sent" before the broker has acknowledged it. The PM must decide, per feature, whether that is acceptable or whether the UI needs a "pending / dispatched / acknowledged" state model. This is the single biggest new product decision the release introduces.
• Sizing and cost inputs: MQTT's small payloads and QoS 0/1 semantics affect infrastructure cost modeling — fewer bytes, but you need broker capacity planning (connections, retained topics, session persistence) and now queue worker capacity, queue backend throughput, and a failed-job monitoring path. Add "device messages per minute that will route through the queue" to the sizing worksheet.
• Explicit non-goals: this package still does not provide queue configuration, schema validation, retry/backoff policy tuning, dead-letter handling, ordering guarantees, or multi-tenant topic isolation. Mqtt::queue() hands you the mechanism; the retry budget, backoff curve, failure alerting, and ordering semantics are product-level design decisions the PM owns. Note that queue retries are at-least-once — duplicate device commands are now a realistic failure mode worth designing for (idempotency keys, device-side dedupe).

When to Consider This Package

Adopt when:

• You are on Laravel 8+/PHP 8+ and need publish and/or subscribe against a standard MQTT 3.1.1 broker as a small part of a larger feature.
• You need publishing off the request path (new): Mqtt::queue() gives you async publish without writing your own job class or adapter for the common case. If your feature is "user does X → N device commands go out," this materially shortens the integration.
• Your messaging volume is modest and your team is PHP-centric — avoiding a second runtime is worth more than protocol-level control.
• You need a throwaway or internal prototype to validate device connectivity before committing to a broker vendor or a dedicated ingestion service.
• You wrap it behind your own MessagingClient interface so the transport can be swapped later. This is the single most important adoption condition, and it now covers both publish() and queue() so the async API shape stays interchangeable.

Look elsewhere when:

• Maturity and support risk matter. ~100 GitHub stars, zero known dependents, and a single maintainer means no community backstop. The v3.3.0 async feature is a single PR with no downstream adoption history — treat it as newer and less proven than the synchronous path, and do not put it on a revenue-critical path without your own test coverage. Otherwise fork it internally or use php-mqtt/laravel-client, which has broader adoption and a clearer maintenance story.
• You need MQTT 5 features (shared subscriptions, message expiry, reason codes) or fine-grained control over keep-alive, clean session, TLS client certs, and reconnect strategy — verify line by line before committing. The release does not change this.
• You need strict ordering or exactly-once delivery. Queued publishing actively works against ordering unless you pin a single worker or use queue-level ordering primitives; validate this explicitly if commands to the same device must apply in sequence.
• You need high-throughput ingestion (thousands of messages/sec). Async publish helps the producer side but is not an ingestion architecture; use a long-running process (Octane, Swoole, or a dedicated consumer) rather than HTTP request lifecycles.
• You are building browser-facing real-time UI — use Reverb/Pusher/Mercure instead; MQTT over WebSockets adds operational complexity for little gain.
• Your cloud provider already offers a managed path (AWS IoT Core, Azure Event Grid/IoT Hub, GCP Pub/Sub) with SDKs and IAM — the Laravel wrapper adds little there beyond convenience.

Migration and exit costs remain low (MIT, thin API), which lowers the cost of being wrong — but the half-day spike now needs to cover more: TLS, auth, reconnect, subscribe-in-a-queue-worker behavior plus Mqtt::queue() against your intended queue driver (Redis vs. database vs. SQS behave very differently), behavior when the broker is down at job execution time, retry/failed-job behavior, and whether retries can produce duplicate device commands. Budget a full day rather than a half.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a small, free, open-source connector that lets our Laravel application talk to an MQTT message broker — the standard plumbing for connected devices and sensor data. The new v3.3.0 release adds asynchronous publishing, which means device commands can be sent in the background instead of making our users wait, removing the main performance objection to building device features on our current stack. It is glue, not a platform bet, and it still does not require hiring a second engineering team or standing up a new service. Risk is unchanged and is about maintenance profile, not capability: one maintainer, roughly a hundred stars, and the async feature is brand new. So we isolate it behind our own interface and expect to swap or fork it. Cost to try is a few engineering days; cost to be wrong is low.

For engineering leads: MIT-licensed, publish/subscribe against a standard broker, drop-in via Composer. v3.3.0 adds Mqtt::queue() — async publishing via the Laravel queue. That is a genuine improvement to production ergonomics, but it is one PR deep with no downstream usage, so treat it as unproven and cover it with our own tests. The value remains speed of integration, not capability. We should (1) pin the version, (2) wrap it in an internal adapter with a single publish/subscribe contract that hides both publish() and queue(), (3) define explicitly which features may accept eventual consistency from the queue and which need synchronous confirmation, (4) run subscribe loops in a supervised queue worker rather than a web request, (5) add failed-job alerting and idempotency on the device-command side, and (6) benchmark it against php-mqtt/laravel-client in the same spike. If it fails the spike, we lose a day; if we adopt it raw and it stalls, we inherit an unsupported dependency in a customer-facing path.

Recommendation: Approve a time-boxed spike, not a commitment. The v3.3.0 release strengthens the case by removing the request-latency objection, but it does not change the maintenance risk and introduces new delivery-semantics decisions we must own. Gate production use on the adapter abstraction, a documented broker choice, a documented consistency policy (which actions may report success before broker acknowledgement), queue monitoring, and a fallback plan.