Mqtt Laravel Package

Product Decisions This Supports

Feature scope and prioritization

• Decides whether real-time/IoT capabilities (device telemetry ingestion, remote command dispatch, live status dashboards, push-style notifications) can live inside the existing Laravel monolith versus requiring a new service in another language.
• Informs roadmap sequencing: if device connectivity is a near-term differentiator, an MQTT client in PHP removes a multi-quarter detour into a polyglot service; if it's a "someday" capability, deferring avoids premature runtime changes (see Swoole caveat below).

Architecture and build-vs-buy

• Supports the "buy the broker, build the client" split: purchase a managed MQTT broker (EMQX Cloud, HiveMQ, AWS IoT Core, Mosquitto self-hosted) while implementing publisher/subscriber integration in-house with this package — no new language runtime, no extra headcount.
• Frames the alternative explicitly: a Node/Go/Python sidecar or managed IoT platform is the "buy" path for connectivity; this package is the "build" path that keeps ownership in the PHP team. The trade is operational complexity (coroutine runtime) versus cross-team coordination and a second deployment surface.
• Informs internal event-bus decisions: MQTT 5.0 with shared subscriptions and message expiry can serve low-to-moderate internal pub/sub needs, but should be benchmarked against Redis pub/sub, RabbitMQ, or Kafka already in the stack — do not adopt a second messaging system without a device-driven reason.

Concrete use cases worth sizing

• Laravel admin/ops consoles that publish commands to field devices and consume acknowledgements.
• Background workers that subscribe to telemetry topics and persist into Eloquent models, feeding analytics or alerting.
• Protocol-level inspection (the package parses and constructs packets) for integration tests, broker mocking, and CI fixtures — a real cost saver when MQTT is otherwise hard to test.
• MQTT-over-WebSocket delivery for live UI updates where WebSocket infrastructure is already MQTT-based.

Decision inputs PM should demand before committing

• Confirm the deployment runtime: the client is coroutine-based and implies Swoole/OpenSwoole (Laravel Octane or a dedicated long-running Artisan worker). This is a platform decision, not just a library choice, and should be priced into the estimate.
• Define QoS, reconnect, and backpressure expectations up front — the library gives you protocol correctness, not application-level delivery guarantees.

When to Consider This Package

Adopt when:

• The team is PHP/Laravel-centric and a separate messaging service would cost more in coordination, hiring, or operational overhead than it saves.
• You need genuine MQTT protocol coverage across 3.1, 3.1.1, and 5.0 — including 5.0 semantics such as reason codes, user properties, shared subscriptions, and message expiry — rather than a thin wrapper with partial support.
• Swoole/OpenSwoole is already present or is a sanctioned platform direction (e.g., Octane adoption on the roadmap), so the runtime dependency is not net-new risk.
• Connection counts and throughput are modest and predictable — hundreds to low thousands of long-lived client connections, not fleet-scale ingestion.
• You want packet-level visibility for testing, mocking, or diagnostics, not just a publish/subscribe façade.
• Apache-2.0 licensing and standard-protocol lock-in avoidance matter to legal or procurement.

Look elsewhere when:

• The org is committed to PHP-FPM/serverless request-response with no appetite for a long-running coroutine runtime — the fit is poor and the workaround cost is high.
• You need high-volume, high-reliability ingestion (tens of thousands of connections, strict delivery SLAs); use a purpose-built service or managed IoT platform with an SLA.
• You need vendor support, contractual uptime, or a security review with a named vendor — this is a community package with a small maintainer base; bus factor and CVE response time are real diligence items.
• You need a broker, MQTT bridging, MQTT-SN, or device provisioning/fleet management — this is a client, not a platform.
• Your messaging needs are internal-only and already served by Redis/RabbitMQ/Kafka; adding MQTT purely for novelty is a net negative.
• The team lacks Swoole operational experience and has no plan to acquire it — the failure mode is silent connection death in production, not a compile error.

Diligence items before commitment: confirm active maintenance and release cadence (a release dated 2026-01-16 is a positive signal), scan the issue tracker for reconnect/keep-alive and MQTT 5.0 edge-case reports, and require a spike that proves behavior under broker restart, network partition, and credential rotation.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can add device connectivity and real-time messaging to the product without hiring a second engineering stack or standing up a new service. This is an Apache-2.0, standards-based MQTT client for PHP that speaks the current protocol versions, so there is no license cost and no proprietary lock-in — we can change brokers or move to a managed IoT platform later without rewriting the integration. The principal cost is not the library; it is adopting a long-running PHP runtime (Swoole/Octane) that our workers need, which is a platform investment with reuse beyond this feature. Recommend approving a two-to-three week spike to validate runtime fit and operational behavior before committing to a roadmap date.

For engineering:

• Protocol coverage is the differentiator: 3.1, 3.1.1, and 5.0, including 5.0 features teams usually hand-roll (reason codes, user properties, shared subscriptions, message expiry).
• Coroutine client means efficient long-lived connections and a natural fit for Octane or a dedicated subscriber worker — but it is not usable in vanilla FPM request lifecycles, so the integration boundary must be an explicit worker/queue design.
• Packet-level parsing gives us testable seams: we can assert on wire format and mock brokers in CI instead of relying on a live environment.
• What the library will not do for us: connection lifecycle policy, QoS-2 duplicate handling at the application layer, dead-letter/retry semantics, observability, or secrets rotation. Budget for these explicitly.
• Risk register: small maintainer base (bus factor), Swoole operational learning curve, and no commercial support. Mitigate with a pinned version, an internal integration wrapper to limit blast radius, and a documented fallback to a sidecar service if the runtime proves untenable.
• Ask: a timeboxed spike covering connect/reconnect under broker restart, credential rotation, 5.0 feature verification, and a load test at our expected connection count.