Client Laravel Package

Technical Evaluation

Architecture fit: php-mqtt/client is a framework-agnostic MQTT 3.1.1 client, not a Laravel package. It fits Laravel behind a thin internal adapter: an MqttPublisher service for outbound messages and an Artisan-based subscriber worker for inbound messages. Good fit for IoT command/control, telemetry ingestion, device events, and broker-to-app integration. Poor fit for synchronous web requests or latency-critical paths because client operations are blocking and connection lifecycle must be managed explicitly.

Integration feasibility: High for basic pub/sub. Install via Composer, wrap client creation in a service provider, centralize broker/TLS/auth/QoS settings in config/mqtt.php, and use Laravel’s PSR-3 logger. TLS, username/password auth, QoS 0/1/2, keep-alive, timeouts, and callbacks are available. There is no native Laravel auto-discovery, facade, or queue integration, so those are our build items. A broker such as Mosquitto, EMQX, HiveMQ, or AWS IoT Core is still required.

Technical risk: Medium. The synchronous client model requires deliberate handling of reconnect/backoff, graceful shutdown, memory growth, duplicate delivery, and backpressure in long-running workers. MQTT 5 features such as shared subscriptions, message expiry, and reason codes are unavailable; workarounds are broker-specific. The project has modest community signals at ~439 stars and unknown repository ownership, so bus factor and security-patch responsiveness need validation. MIT licensing and dependency-light code reduce lock-in.

Key questions: What message volume, throughput, and latency SLOs are required? Which QoS and delivery semantics are mandatory? Which broker and MQTT version are targeted, and is MQTT 5 on the roadmap? Is mTLS, JWT, OAuth, or username/password auth required? How will multi-tenant topic ACLs work? What worker topology and scaling model is acceptable? What existing MQTT tooling must be replaced? What observability, audit, and retention requirements apply? What support/SLA and security-patching expectations exist?

Integration Approach

Stack fit: Use Laravel’s container, config, logging, queues, and events. Bind an MqttClientFactory and MqttPublisher; publish from queued jobs or domain listeners rather than controllers. For subscriptions, create a dedicated mqtt:subscribe Artisan command managed by Supervisor or Kubernetes, emitting Laravel events/jobs for downstream processing. Keep the package behind an internal interface so the client can be swapped later. Store TLS certificates and credentials in secrets management, not source control.

Migration path: If replacing shell-based mosquitto_pub/sub calls or another PHP MQTT library, introduce an adapter and preserve existing topic contracts. Pilot with one bounded context. Provide a local Docker Compose broker for development and CI. Migrate outbound publishing first because it is simpler, then the subscriber worker, then cut over with a feature flag and short dual-run period.

Compatibility: Verify the target PHP/Laravel matrix, required extensions such as OpenSSL and sockets, broker support for MQTT 3.1.1, TLS versions/ciphers, and QoS behavior. Confirm Composer constraints against the Laravel version in use. Validate PSR-3 logging integration and QoS 1 duplicate handling; test QoS 2 only if the use case justifies its overhead. Check that no MQTT 5-only broker features are assumed.

Sequencing: 1) Run a spike and broker proof of concept; 2) build the wrapper, config, and automated tests; 3) ship the queued publish path; 4) add the subscriber worker with observability; 5) harden TLS, auth, and certificate rotation; 6) run load and failure tests; 7) stage rollout with runbooks and rollback criteria.

Operational Impact

Maintenance: We own the adapter, worker lifecycle, and Laravel integration. The package itself is small, but community size means we should pin versions and monitor releases/security advisories. Certificate rotation, credential rotation, broker ACLs, and topic governance become recurring operational work. MIT reduces licensing risk, not ownership risk.

Support: Establish an internal L2/L3 runbook covering broker connectivity, TLS/auth failures, queue backlog, worker restarts, and dead-letter handling. Commercial support exists for the broker, not for this package. Budget explicit on-call ownership and escalation paths.

Scaling: Outbound publishing scales horizontally through Laravel queue workers. Inbound subscribers scale by running multiple workers with unique client IDs; MQTT 3.1.1 lacks portable shared subscriptions, so use broker-specific shared subscriptions or topic partitioning. QoS 1/2 increases broker and client overhead. Monitor connection counts, message rates, memory, queue depth, and reconnect storms. For very high throughput or strict latency, evaluate an async client or move ingestion out of PHP.

Failure modes: Broker outage or unreachable network; expired or mismatched TLS certificates; authentication failure; duplicate QoS 1 delivery; message loss on clean-session reset or worker crash; poison messages; blocking loops stalled on network I/O; memory growth in long-running workers; reconnect stampedes; queue backlog; certificate rotation outages. Mitigate with backoff plus jitter, idempotency keys, dead-letter topics, health checks, graceful shutdown, alerting, and failure/load testing.

Ramp-up: Laravel/PHP engineers can become productive in days. MQTT semantics, QoS behavior, TLS operations, and worker supervision need roughly one to two sprints including adapter build, observability, and failure testing. TPM should gate full rollout on a pilot, defined SLOs, broker/security sign-off, and an owned operational runbook.