Laravel Client Laravel Package

Product Decisions This Supports

• Platform upgrade timing (Laravel 13 readiness): v1.8.0 adds Laravel 13.x compatibility, which removes this package as a blocker on a framework upgrade roadmap. If our Laravel upgrade epic is gated on third-party dependency audits, this package can be moved from "blocked/unknown" to "cleared" — a concrete unblocking signal for quarterly planning.
• Build vs buy for device/MQTT messaging: Confirms we can keep consuming an existing open-source Laravel MQTT client rather than building a broker client abstraction in-house. The maintenance cadence (tracking new Laravel majors) is a proxy for healthy stewardship, which lowers the total cost of ownership case for "buy/adopt."
• Feature feasibility for IoT/pub-sub use cases: Enables product bets that depend on publish/subscribe messaging — device telemetry ingestion, command dispatch to hardware, background job triggering from broker events, and server-side reactive workflows. Useful when scoping an MVP that needs real-time-ish device communication without standing up a custom integration layer.
• Roadmap risk register: A minor, compatibility-only release is a low-drama data point. It signals no breaking API changes, so no migration work or feature freeze is required — keep it off the "must schedule engineering time" list.
• Support matrix decisions: Lets us declare official support for Laravel 13 in our own product/platform docs once we validate the upgrade, and informs whether we pin ^1.8 in composer constraints for new services.

When to Consider This Package

Consider adoption when:

• We are on (or planning) a modern Laravel version and need to talk to an MQTT broker from PHP without writing protocol handling ourselves.
• The messaging needs are application-tier and moderate volume: emitting events, consuming device messages into jobs, syncing state between services and an IoT broker.
• We want idiomatic Laravel integration — configuration, facades/DI, queue and event integration — rather than a raw protocol library bolted on.
• We value a dependency that demonstrably tracks Laravel major releases; v1.8.0 is evidence of that, though a single compatibility PR is a weak signal on its own — check commit/release frequency over the last 12 months before treating it as "actively maintained."

Look elsewhere when:

• Throughput, latency, or connection-pooling requirements exceed what a PHP request/worker lifecycle can serve — a dedicated service (Go/Node/Rust) or a managed IoT platform is the better call.
• The product need is browser-facing real-time updates — Laravel Reverb/Pusher-style WebSockets are the more direct fit than MQTT.
• We need guaranteed enterprise support, SLAs, or a vendor to escalate to; this is community-maintained and bus-factor is a real consideration.
• We require MQTT 5 feature parity, fine-grained QoS guarantees at scale, or broker-side clustering — verify against the underlying php-mqtt/client capabilities before committing.
• We only need simple internal job dispatch — Laravel's native queue is simpler and adds no dependency.

Adoption caveats: pin the version, confirm the underlying client library's Laravel 13 support too (this package wraps it), and add a smoke test in CI so a future major bump surfaces early.

How to Pitch It (Stakeholders)

For executives (one paragraph): A dependency we rely on for device/message-broker connectivity just shipped compatibility with the newest Laravel release. This is a small, non-breaking maintenance update — no feature changes, no rework, no cost. Its value is strategic rather than functional: it clears a potential blocker on our framework upgrade path and confirms the library is still being maintained by its community. Recommendation: no new investment, keep it in the stack, and let engineering pin the updated version as part of the normal upgrade cycle.

For engineering leads: v1.8.0 is a single change — Laravel 13.x compatibility (PR #79) — with no API changes, so upgrade risk is minimal. Action: bump the constraint to ^1.8, verify the wrapped php-mqtt/client also supports Laravel 13, and run the existing MQTT integration tests in CI before rolling forward. Because this is a community package, note it in the dependency-risk register and re-evaluate at each Laravel major rather than treating this release as durable proof of long-term maintenance.