Gateway Worker Laravel Package

Product Decisions This Supports

• Realtime feature roadmap: Persistent-connection workloads — chat/IM, live notifications, presence and “typing” indicators, support inboxes, in-app activity feeds, auction/bid updates, live dashboards, and collaborative editing signals.
• Build vs. buy: GatewayWorker is the “buy” (MIT, no license cost) option for the transport and connection-management layer of realtime. It does not supply product logic, persistence, or delivery guarantees — those remain your build.
• Architecture decisions: It forces an explicit split between gateway processes (connection/socket handling) and business worker processes (message handling), coordinated by a register service. That is a durable design pattern; adopting it early avoids a later rewrite when you outgrow a single-node WebSocket server.
• Non-HTTP use cases where PHP is otherwise awkward: raw TCP/UDP endpoints, binary or custom line protocols, device/IoT telemetry ingestion, and long-poll/WebSocket gateways behind a standard HTTP app.
• Scaling/co-location decisions: Multi-machine horizontal scaling of gateways with centralized routing lets you size connection capacity independently of business logic — useful for capacity planning and cost forecasting per 10k concurrent connections.
• Scope boundary for the core product: Because it runs as standalone daemons outside the request lifecycle, it clarifies whether your team is buying into an additional runtime (process supervision, deploys, observability) versus an in-request feature.
• Make-vs-integrate for Laravel teams: If the product only needs Laravel Broadcasting + Echo-style events, this competes directly with Laravel Reverb (first-party) and hosted Pusher/Ably. The decision hinges on whether you need custom protocols, raw TCP, or extreme connection counts.

When to Consider This Package

Consider it when:

• You need persistent connections (WebSocket, TCP, UDP) with high concurrency in PHP, and want to stay in one language/runtime rather than adding Node/Go services.
• You need gateway/worker separation and multi-machine scale-out out of the box, with connection state isolated from business logic.
• You require custom or non-HTTP protocols (binary frames, device telemetry, proprietary handshakes) that HTTP-centric realtime tools don’t model well.
• You are comfortable operating long-running PHP daemons (Supervisor/systemd, graceful restarts, health checks, memory ceilings) and have a place to deploy them.
• You need a permissive license with no per-connection vendor pricing, and your concurrency economics favor self-hosting.
• You already run or plan to run Workerman-based services (e.g., webman), where the operational model is shared.

Look elsewhere when:

• Your need is plain Laravel Broadcasting (private/presence channels, Echo client). Use Laravel Reverb for first-party integration, or Pusher/Ably for zero-ops.
• You want managed infrastructure with SLAs, global edge, and no daemon operations — hosted pub/sub is cheaper than your team’s on-call time.
• You need durable messaging semantics (replay, at-least-once, consumer groups, retention). This is a connection framework, not a message broker — pair it with Redis Streams/Kafka/RabbitMQ or choose a broker-native product.
• Your stack is Node/Go-centric or the team has no PHP process-operations experience; Socket.IO/Centrifugo will have a lower total cost of ownership.
• You are on serverless/managed PHP hosting where long-running processes aren’t available.
• You need server-sent events only — lighter options (Mercure) suffice.

Diligence notes: ~1k GitHub stars and a “0 dependents” signal are not red flags of abandonment — GatewayWorker is a deployable framework rather than a library pulled in transitively, and it sits inside the much larger Workerman ecosystem. Last release mid-2025 indicates active maintenance. Validate instead: PHP version support, documentation quality for your exact protocol, and the availability of maintainers/community for production incidents.

How to Pitch It (Stakeholders)

For executives: This is a free, MIT-licensed framework for the realtime plumbing behind chat, notifications, and live updates. It lets us build those features in PHP — the language we already staff — instead of standing up a second engineering stack, and it scales horizontally by adding gateway machines as concurrency grows. The trade-off is operational: it runs as its own always-on service, so it adds deployment and monitoring work, plus a dependency on a smaller open-source project. Recommendation: adopt narrowly for the specific realtime surface where HTTP-based options fall short, with a spike to confirm ops cost; if we only need standard Laravel event broadcasting, use the first-party Reverb path and revisit this when we hit its limits.

For engineering: GatewayWorker gives us a proven gateway/worker/register topology: gateways hold sockets, workers run business logic, register coordinates membership, so we scale connections and processing independently. It supports WebSocket/TCP/UDP and custom protocols, and it is a deployable framework, not an in-request library — meaning no middleware, no framework request lifecycle, and no shared in-memory state inside the process. We must design for stateless workers, externalize session/presence state to Redis, handle auth at the handshake, terminate TLS at the edge, and add Supervisor, health checks, graceful reloads, and connection-count metrics before launch. If our requirement is simply “broadcast Laravel events to Echo,” Reverb is the lower-risk default; GatewayWorker earns its place when we need non-HTTP protocols, very high connection counts, or cross-machine gateway fan-out.