Gatewayclient Laravel Package

Product Decisions This Supports

• Real-time feature feasibility (chat, notifications, presence, live dashboards). GatewayClient is the piece that lets a Laravel/PHP web process push a message to a WebSocket client that is held open by a separate GatewayWorker process — without a Node/Go sidecar and without a third-party SaaS broker. Any roadmap item phrased as "notify the user instantly" depends on a decision like this one.
• Build vs. buy for the realtime transport layer. Choosing GatewayWorker + GatewayClient is the "build/self-host" branch of the Pusher / Ably / Firebase / Soketi decision. That is a cost, compliance, and ops decision, not a library decision — GatewayClient is the cheap, low-risk glue that makes the self-hosted branch viable from inside PHP.
• Architecture boundary: web app vs. realtime tier. Adopting this package formalizes a split between the Laravel request/queue workers (producers) and the GatewayWorker cluster (connection holders). That boundary is worth approving explicitly — it affects deployment topology, horizontal scaling, and who owns on-call.
• Delivery semantics as a product promise. GatewayClient sends fire-and-forget messages over the internal gateway port. There is no offline queue, no ACK, no replay. Before you commit to features like "unread message count" or "no lost notifications," decide that persistence + reconnect-and-resync is app-side responsibility. That's a product requirement, not an implementation detail.
• Scaling / cost posture. Self-hosting long-lived connections is materially cheaper than per-connection SaaS pricing at high concurrency, and it's the right call when message volume is high but payloads are small (presence pings, counters, chat lines). The inverse is true for low-volume, spiky traffic.
• Buy-adjacent alternatives worth putting on the same slide: Laravel Reverb (first-party, Laravel 11+), Laravel Echo + Soketi/Pusher, Redis pub/sub + a thin fan-out service, or plain SSE/polling where the UX tolerates it.
• Roadmap sequencing. If you're not already running GatewayWorker, this package is not the decision — adopting GatewayWorker is. GatewayClient is a ~1-file-complexity dependency you add afterward; it should never be the reason a roadmap item is greenlit.

When to Consider This Package

Consider it when all of the following hold:

• You already run, or have already committed to, GatewayWorker/Workerman for your WebSocket tier. GatewayClient is meaningless without it.
• Your producer side is PHP, ideally Laravel, and you want to avoid introducing a second runtime (Node/Go) just to call sendToUid / sendToGroup.
• You need server-originated push — queued jobs, model events, webhooks, admin actions — into connections held by a different process, not just client-to-server messaging.
• You want to avoid per-connection SaaS cost or keep message content on your own infrastructure for data-residency/compliance reasons.
• You're comfortable operating long-running supervised processes (Supervisor/systemd), internal ports, and a Register service — i.e., you have or will buy basic ops capability.
• You need only simple addressability: by client ID, by UID, by group/room, broadcast-to-all, online checks, force-disconnect. If your needs are more exotic, you'll be building it anyway.

Look elsewhere when:

• You're on Laravel 11+ and Reverb fits — a first-party server plus first-party broadcasting integration will beat hand-wiring a third-party SDK for most teams.
• You want a turnkey broadcast driver with channels, auth, presence, and an official client. GatewayClient ships none of that; you write the BroadcastDriver/service provider yourself, and you write your own auth and channel conventions.
• You need delivery guarantees (at-least-once, ordering, offline queues, replay). Plan on a persistent store plus client-side resync; the package will not give you this.
• You need multi-language producers or an event bus consumed by non-PHP services — pair Workerman with Redis or a real broker instead of a PHP-to-PHP gateway protocol.
• Your realtime volume is low or bursty; managed SaaS or SSE removes a whole tier of operational burden for a rounding-error of cost.
• You lack capacity to run and monitor a stateful connection tier. Undersupervised or single-node GatewayWorker deployments fail in user-visible ways.

Adoption cautions worth stating plainly in the decision record: 347 stars and zero dependents on Packagist are modest ecosystem signals — mitigated by the fact that it is the Workerman author's own reference SDK and was released/maintained as recently as January 2025. The internal gateway port is trust-based; anyone who can reach it can broadcast to your users, so network isolation is a hard requirement, not a hardening nice-to-have.

How to Pitch It (Stakeholders)

To executives (one paragraph): We can deliver real-time push — chat, live notifications, presence — from inside our existing PHP application without paying per-connection SaaS fees or standing up a second engineering stack. The library itself is tiny, MIT-licensed, free, and maintained by the same author as the underlying server, so the code risk is negligible; the real commitment is operating one always-on service, which is a known, bounded piece of infrastructure. The trade-off is explicit: we own uptime and delivery guarantees instead of renting them, and we accept that messages are best-effort, so anything that must never be lost is stored in the database first and reconciled on reconnect.

To engineering (the ask): Add workerman/gatewayclient as the producer-side SDK into a GatewayWorker cluster. One config value (registerAddress), a thin Laravel service provider exposing a Realtime facade over sendToUid / sendToGroup / isUidOnline, and a queue-safe wrapper so broadcast jobs don't block request cycles. Non-negotiables: the internal gateway port stays on a private network, an auth/handshake layer sits in front of it, and the Gateway/Register processes run under Supervisor with health checks and alerting. Budget the work as infrastructure, not as a feature — the feature work is the product-layer contract (rooms, auth, persistence, resync), and that's where the real estimate lives.