Client Laravel Package

Product Decisions This Supports

• IoT / device-facing feature viability: If you're evaluating whether to add device telemetry ingestion, command dispatch, or real-time status sync to a Laravel product, this package makes the broker side of that conversation cheap to prototype. A PM can scope an internal spike in days rather than weeks to decide whether IoT is a real roadmap lane or a distraction.
• Build vs. buy on messaging transport: Because it is dependency-light and MIT-licensed, it shifts the build/buy calculus away from "buy a managed MQTT SaaS" toward "run a broker (Mosquitto, EMQX) and use a thin client." That is a genuinely different cost structure — lower recurring spend, higher ops burden — which is a decision worth surfacing to leadership rather than defaulting to a vendor.
• Integration surface for third-party data: Many industrial, logistics, and hardware partners speak MQTT natively. This package is what makes a Laravel app a first-class participant in those ecosystems instead of demanding partners adopt webhooks or REST, which they often can't.
• Async / long-running workload planning: Subscribing means long-lived processes and workers, not request-response. That has direct implications for queue architecture, deployment topology, and hosting cost — decisions that should be made deliberately, early, and with engineering input rather than discovered in staging.
• QoS as a product-tier lever: The support for QoS 0/1/2 enables a real product distinction — "at-least-once" reliability guarantees sold as a premium tier versus best-effort defaults. This is a rare case where a protocol primitive maps cleanly onto pricing.
• Security posture for compliance conversations: TLS and username/password auth are table stakes, but their presence lets you answer security questionnaires for connected-device scenarios without a "we'd have to build that" caveat.
• Use cases worth trialing: internal alerting and notification fan-out, sensor/telemetry dashboards, manufacturing or fleet status views, and cross-service event bus for lightweight internal messaging where Kafka is overkill.

When to Consider This Package

Consider it when:

• The domain genuinely speaks MQTT — hardware, sensors, embedded devices, industrial or logistics partners — and you need PHP to participate rather than to be the broker.
• You want a cheap, reversible experiment. The dependency-light profile and MIT license mean low sunk cost if the hypothesis fails, which is exactly what you want for an unproven roadmap bet.
• Your stack is already Laravel/PHP 7.4+ and you'd rather keep one runtime than introduce a Python or Go sidecar purely for messaging.
• You need configurable keep-alive, timeouts, clean sessions, and PSR-3 logging — the operational knobs that determine whether a long-running subscriber survives production, not just a demo.
• You are publishing messages (outbound commands, notifications, fan-out) more than you are building a high-throughput subscriber fleet.

Look elsewhere when:

• Throughput or scale is the core requirement. A pure-PHP client in a long-running process has real ceiling and memory characteristics; a dedicated worker in Go/Node, or a managed broker plus native clients, will serve high message volumes better.
• MQTT 5.0 features are needed — shared subscriptions, message expiry, request/response patterns, richer reason codes. This is 3.1.1 only, and that constraint is architectural, not cosmetic.
• You need a broker, not a client. This is strictly the client; running Mosquitto/EMQX/HiveMQ and its operational ownership is a separate cost that must be in the business case.
• Serverless or short-lived request hosting. Persistent subscription loops fit poorly with platforms that assume ephemeral execution; forcing it invites fragility.
• The 439-star / single-maintainer profile is a governance concern. For a customer-facing, revenue-critical path, weigh bus-factor and long-term maintenance. Being MIT means you can fork; it does not mean you should have to.
• You actually just need pub/sub between your own services. Redis pub/sub or Laravel's native broadcasting/queues are simpler, better understood by the team, and already in the stack. Reaching for MQTT internally is often architectural cosplay.

How to Pitch It (Stakeholders)

For executives — one paragraph: This is a small, free, permissively licensed PHP library that lets our existing application talk to the standard protocol used by connected devices and industrial partners. The strategic value is option value at low cost: for a few days of engineering we can validate whether device telemetry, remote commands, or hardware-partner integrations are a real business line for us, without signing a managed-service contract or re-platforming. It also gives us a credible answer to partners who ask "can you integrate with our MQTT feed?" — today that answer is likely no. The risk is bounded: MIT license, no vendor lock-in, minimal dependencies, and it's a client only, meaning we keep control of the broker and the data.

For engineering — the ask: Spike a single long-running subscriber and a publisher against a locally hosted broker. Validate three things specifically: (1) reconnect and clean-session behavior under broker restarts, (2) memory stability over a 24-hour subscribe loop, and (3) whether the PHP 7.4 floor and 3.1.1-only protocol support create friction with our target partners. Report back the operational topology we'd need — worker process, supervision, deployment target — as a cost estimate, not a design doc.

Framing to use: "Cheap probe, clear kill criteria." We are not committing to IoT; we are buying information about whether IoT is worth committing to. And be explicit about the honest counterargument — this is a small, single-maintainer package, and if the spike succeeds, part of the follow-up decision is whether we're comfortable owning a fork if upstream stalls. That is a maintenance question for leadership, not a technical one, and it should be asked before the feature ships to customers, not after.

What success looks like: A go/no-go on IoT with real evidence, a defensible answer on broker ownership and ops cost, and no customer-facing commitment made on the strength of a 439-star library.