Laravel Broadcaster Laravel Package

Product Decisions This Supports

• Real-time feature delivery without owning infrastructure: This package lets the team ship live features (in-app notifications, presence, chat, collaborative editing indicators, live dashboards, order/status tracking) by swapping Laravel's broadcasting driver to Ably — no WebSocket fleet, Redis pub/sub, or Reverb servers to operate.
• Build vs. buy for real-time transport: Provides the concrete "buy" path. The alternative — self-hosting Laravel Reverb/Soketi or building a custom socket layer — is a recurring engineering tax (scaling, sticky sessions, connection fan-out, failover). This package reduces that decision to a config change and a vendor contract.
• Migration optionality (vendor de-risking): Because it implements Laravel's native broadcasting contract, Pusher can be swapped for Ably (or back) largely via driver/config changes. This preserves leverage in vendor negotiations and keeps a credible exit ramp if Ably pricing, reliability, or roadmap stops fitting.
• Global/edge scale and mobile reach: Relevant where users are geographically distributed or predominantly on mobile/flaky networks — Ably's managed edge and connection handling shift the "will real-time work on 3G in APAC?" risk off our roadmap.
• Roadmap sequencing signal: Laravel 13 support in v1.0.8 signals the vendor tracks framework releases promptly. That lowers the risk of pinning a Laravel upgrade on a stale third-party driver — a common cause of delayed platform upgrades.
• Scope/effort estimation: Adoption cost is low (composer require, driver config, channel authorization), which makes real-time work estimable as a small story rather than a multi-sprint infrastructure epic — useful when triaging "should this be in the next release?"

When to Consider This Package

Consider adopting when:

• The product roadmap includes real-time, user-facing features (notifications, presence, live updates, chat, multiplayer state) and the team does not want to own socket infrastructure.
• The app already uses (or would naturally use) Laravel's broadcasting/events system — ShouldBroadcast, private/presence channels, Echo on the client.
• You need scale, global distribution, or managed uptime SLAs that would be expensive to engineer in-house.
• You need a Pusher-compatible API without Pusher, or want a low-effort migration path off a current provider.
• Mobile-first or unreliable-network clients are a significant segment (managed connection recovery matters).
• Compliance/ops constraints favor a vendor with documented SLAs over a self-run service.

Look elsewhere when:

• Real-time needs are trivial or internal-only (a single admin dashboard) — Laravel Reverb or even polling may be cheaper and simpler.
• Cost sensitivity at very high message/connection volume: per-message pricing can outgrow self-hosted infrastructure at sustained scale. Model Ably spend against projected MAU/connections before committing.
• Hard data-residency or on-prem requirements that rule out a third-party SaaS transport.
• The team is standardized on Pusher or a cloud provider's real-time service (AWS AppSync/IoT, GCP) and consolidation outweighs Ably's ergonomics.
• You need transport semantics Ably doesn't cover well (e.g., heavy binary streaming) — validate fit first.
• You cannot accept a dependency on a third-party driver for a critical path; note the package is a thin, community/vendor-maintained adapter — pin versions and watch release cadence.

How to Pitch It (Stakeholders)

For executives: Real-time capability is a product expectation, not a differentiator — but building and running the infrastructure behind it is a permanent operational cost with no customer-visible payoff. This package lets us deliver live features on Ably's managed global network through a small configuration change rather than an infrastructure program. It keeps us on Laravel's standard broadcasting interface, so we are not locked in: we can change providers without rewriting features. The cost shifts from engineering headcount and on-call burden to a predictable vendor line item, and the latest release (v1.0.8) adds Laravel 13 support, confirming the integration stays current with our framework upgrades.

For engineering: It's the official Ably broadcasting driver for Laravel — a drop-in for the Pusher driver implementing Laravel's broadcasting contract. Adoption is composer require, a driver swap in config/broadcasting.php, channel authorization via the provided routes, and Echo on the client. No new infrastructure to deploy. Note the trade-offs to validate during a spike: vendor SDK coupling, channel-authorization endpoint correctness for private/presence channels, per-message cost modeling at projected volume, and version pinning — it's a third-party adapter, so we should track its release cadence (v1.0.8 ships promptly after Laravel 13). Recommendation: run a one-sprint spike on a single non-critical feature to confirm latency, auth flow, and cost curve before standardizing.