Laravel Mercure Broadcaster Laravel Package

Product Decisions This Supports

• Real-time feature delivery: Mercure is an SSE-based pub/sub hub; this package wires Laravel's broadcasting system to it, enabling live notifications, activity feeds, dashboards, collaborative cursors, and progress updates without hand-rolling WebSocket infrastructure.
• Build vs. buy for realtime: Lets you keep the "broadcast event" DX your team already knows (broadcast(new OrderShipped($order))) while delegating fan-out, connection management, and horizontal scaling to a standalone Mercure hub — a defensible middle path between polling (cheap, poor UX) and a fully managed service (fast, recurring cost and vendor lock-in).
• Architecture/roadmap signal: Laravel 13.x compatibility in 3.9.0 shows active upstream tracking, which matters if your roadmap spans the next major Laravel upgrade; adopting now avoids a forced migration later.
• Scope decisions: SSE via Mercure is one-way server→client. If the roadmap requires bidirectional or client-to-client messaging (chat presence, multiplayer state), this is the wrong tool and should be scoped as such rather than retrofitted.
• Use cases: notification bells, background job status, multi-tenant admin live views, auction/bid tickers, CI or deploy status pages — anything where "the user shouldn't have to refresh."

When to Consider This Package

Adopt when:

• You are on a supported Laravel version and want minimal-code realtime with the standard broadcasting API, rather than learning a new abstraction.
• You can operate (or pay for) a Mercure hub — self-hosted Caddy-based hub or a managed offering. The hub is the real dependency; this package is a thin, well-scoped adapter.
• Your realtime needs are server-push dominant, and SSE's one-way model fits the UX.
• You value standards-based transport (SSE/HTTP) over proprietary sockets — good for corporate networks and proxies that block WebSockets.

Look elsewhere when:

• You need bidirectional messaging → Laravel Reverb, Pusher, or Soketi (WebSocket protocols) are the natural fit.
• Your client base is dominated by legacy browsers or native mobile where SSE support/keep-alive handling is awkward → consider FCM/APNs plus a WebSocket path.
• You want zero operational surface → managed Pusher/Ably removes the hub from your on-call rotation.
• Very high fan-out with per-connection authorization nuance may push you toward a platform with richer presence/auth primitives; validate Mercure's private-topic + JWT cookie model against your tenancy requirements first.

How to Pitch It (Stakeholders)

To executives: This is a small, low-risk dependency that gives us live-updating UI without building or staffing realtime infrastructure. It leans on an open standard (Server-Sent Events) and a self-hostable hub, so we avoid per-message SaaS pricing and the lock-in that comes with a proprietary push vendor. The 3.9.0 release adds Laravel 13.x support, which means the package is being maintained in step with our framework upgrade path — a signal that adopting it now won't strand us at the next Laravel major.

To engineering: Thin adapter between Laravel's broadcasting driver contract and a Mercure hub; you keep using events, channels, and ShouldBroadcast. No new mental model, no custom socket server to operate. Trade-off to accept consciously: SSE is unidirectional, so plan client→server interactions over normal HTTP. The hub is stateful infrastructure — budget for its deployment, TLS, JWT signing keys, and health checks in the same way you would for Redis. Confirm the private-channel auth flow and JWT cookie/CORS configuration against our domain and tenancy model before we commit, and pin the version so an upstream Laravel major bump is a deliberate upgrade rather than a surprise.