Laravel Echo Api Gateway Laravel Package

Product Decisions This Supports

• Real-time features without a third-party vendor. This package lets a Laravel app use AWS API Gateway WebSocket APIs as the broadcast transport for Laravel Echo, so "should we build live notifications / presence-lite / job-progress updates?" can be answered yes without adding Pusher or Ably to the vendor stack, the DPA list, or the data-egress footprint.
• Build vs. buy on real-time. The buy-side (Pusher/Ably) wins on DX and presence semantics; the build-side wins on cost at scale, data residency, and keeping events inside the AWS account/VPC boundary. This package materially lowers the build-side cost, which shifts the threshold for choosing it.
• Cost modelling. API Gateway WebSocket pricing is per-message plus per-connection-minute, versus managed pub/sub's connection-count tiers. For notification-style fan-out with modest message volume, the modelled bill is typically a rounding error next to a managed vendor — worth quantifying before renewal.
• Roadmap sequencing. Because the transport is now credible, downstream real-time epics (in-app notifications, live status, collaborative cursors, chat) can be scheduled on their own merits rather than blocked on a procurement/vendor decision.
• De-risking a known operational failure mode. The 0.5.9 reconnect fixes directly target listeners silently going dead after API Gateway's 2-hour connection ceiling. That was the single biggest "we shipped it and it quietly broke in production" risk in this approach — a PM should treat this release as converting a fragile beta into a supportable feature.
• Platform/frontend coordination. Explicit laravel-echo v1 (^1.10) and v2 support removes a cross-team dependency: the frontend doesn't have to pin or upgrade Echo to match the backend, which shortens the coordination tail on any real-time rollout.

When to Consider This Package

Consider it when:

• You are already on AWS for compute and are comfortable owning infrastructure there — this trades one vendor relationship for your existing one rather than eliminating lock-in entirely.
• Your real-time needs are server→client dominant: notifications, status updates, progress bars, feed refreshes, cache invalidation. Fan-in from clients is possible but awkward (separate connect/disconnect routes, postToConnection semantics).
• Message sizes are small and volumes are moderate; API Gateway WebSocket has hard frame and idle-timeout limits that make it unsuitable for large payloads or long silences.
• Cost, data residency, or a "no new subprocessor" constraint is a real decision driver — this is the strongest argument in its favour.
• You can accept a pre-1.0 dependency (0.5.9). Treat the version as pinned; 0.x semver permits breakage in minor bumps, and a maintenance plan is part of the adoption decision, not an afterthought.
• Security review can accept a package that just had its websocket handler hardened. The 0.5.9 fixes are a positive signal, but they also imply the prior surface was under-reviewed — request the diff and confirm what was closed before signing off on customer-facing data on those channels.

Look elsewhere when:

• You need presence or occupancy semantics (who's online, typing indicators, member lists). API Gateway WebSockets have no built-in presence; you would be building and operating that state yourself. Pusher/Ably do this natively and cheaply.
• You need low-latency bidirectional interaction with server-side heartbeats and graceful connection management. The 2-hour connection cap and lack of server-initiated pings are architectural, not bugs — 0.5.9 makes reconnects survivable, not invisible.
• Your team has no appetite for owning AWS WebSocket plumbing, IAM, and connection-tracking tables. The total cost of ownership is engineer-hours, not the AWS bill.
• You are at small scale and Pusher's free/entry tier covers you — the build-side savings don't clear the operational overhead yet.
• You need delivery guarantees, ordering, or replay. This is best-effort transport; durable eventing belongs on SQS/EventBridge behind it.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can deliver in-app real-time updates — live notifications, status changes, progress indicators — on infrastructure we already run, without adding a new SaaS vendor, a new contract, or a new data processor. The cost profile is per-message and per-connection-minute inside our existing AWS spend, which for our expected volume is materially cheaper than connection-tier managed pub/sub. The trade-off is that we own the plumbing and it isn't a fit for presence-rich or chat-grade interactivity; that remains a separate decision. This release is the one that makes the approach reliable enough to put in front of customers, not just demo.

For engineering: 0.5.9 makes this viable. Reconnect handling after API Gateway's 2-hour connection limit was the failure mode that would have silently killed listeners in production; that's fixed, and it's the difference between "works in staging" and "we can support this." Echo v1 (^1.10) and v2 are both supported, so the frontend isn't forced into a coordinated upgrade. The websocket handler was hardened for channel security — pull the diff and review it as part of sign-off, since the existence of these fixes tells us the surface was thin before. Note that we're on a 0.x release: pin the version, treat minor bumps as potentially breaking, and budget for either upstream contribution or a fork if maintenance lags. Recommended next step is a timeboxed spike against a real API Gateway WebSocket stage, measuring reconnect behaviour across the 2-hour boundary before we commit a roadmap slot.