Mercure Notifier Laravel Package

Product Decisions This Supports

• Channel strategy for notifications. This bridge adds Mercure as a transport inside Symfony Notifier, so it directly informs the "realtime in-app" leg of your notification matrix (alongside email, SMS, mobile push). If realtime toasts/badges/live feeds are on the roadmap, this is the cheapest possible wiring for that channel.
• Build vs. buy for realtime infrastructure. It's thin glue between your app and a Mercure hub. The real buy decision is the hub (self-hosted Caddy-based Mercure vs. a managed Mercure or Pusher/Ably), not this package. This bridge mostly de-risks the integration line item to near-zero effort.
• SSE vs. WebSockets architecture call. Mercure is publish/subscribe over Server-Sent Events, which fits PHP's request/response model far better than running your own socket server. This package makes "SSE via Mercure" a credible default for one-way fan-out (order status, job progress, dashboard ticks, collaborative cursors).
• Roadmap sequencing. Useful for scoping features like live activity feeds, admin monitoring dashboards, and long-running-job progress — all of which are painful to fake with polling and cheap to ship with a hub.
• Dependency risk register. The 16-star count is misleading: this is a split package from the Symfony ecosystem, so its real support base is Symfony Notifier, not this repo. That reframes it as low-risk commodity glue rather than an orphan project — but it also means it is not a strategic dependency worth betting differentiation on.
• Make-vs-abstract decision. Because the integration surface is a DSN and a channel registration, the PM call is "adopt but keep a one-line abstraction." That lets you swap Mercure for another transport later without a re-platform.

When to Consider This Package

Adopt when all of these hold:

• Your codebase is Symfony-based, or uses Symfony Notifier specifically. This is a Symfony Notifier bridge; it does nothing in a stock Laravel app, where notifications flow through Illuminate\Notifications, not Notifier.
• You already run, or intend to run, a Mercure hub (self-hosted or managed) and have the JWT/publish credentials sorted.
• You want realtime notifications delivered via framework-idiomatic config (a mercure:// DSN and a notifier channel) instead of hand-rolling HTTP publish calls to the hub.
• Your notifications are one-way, fan-out, tolerant of at-most-once-ish delivery — UI freshness, not financial transactions.
• You're comfortable with SSE as your browser transport and your edge/proxy layer supports long-lived connections.

Look elsewhere when:

• You're a Laravel shop. Use laravel-notification-channels/mercure or the standalone symfony/mercure publisher client called from a Notification/Event listener. Pulling in Symfony Notifier just to reach Mercure adds a parallel notification system you'll regret.
• You need delivery guarantees, offline queueing, or mobile push. Mercure is transport; it doesn't persist or retry for you. Reach for FCM/APNs or a managed pub/sub with replay.
• You need rich per-user authorization and private topics out of the box. Mercure supports private updates via JWT claims, but you own the authorization design and the token-minting service.
• You need a vendor SLA and a support contract. A 16-star split repo gives you neither; a hosted Mercure or commercial pub/sub does.
• You have strict dependency-vetting rules that weigh repo-level popularity metrics. Be prepared to argue the "it's a Symfony split package" point explicitly, or you'll fail the check on optics alone.

How to Pitch It (Stakeholders)

One-liner: A small, MIT-licensed adapter that lets our Symfony notification system push realtime updates through a Mercure hub — a few lines of configuration instead of custom publishing code.

For executives: Cost is effectively zero (MIT, no per-seat licensing). The real spend is operational — running or subscribing to a Mercure hub — and that exists regardless of this package. It's an enabler, not a differentiator: it buys us live UX (status updates, dashboards, progress) without a WebSocket service to build and maintain. Treat it as commodity plumbing; keep the transport swappable so this never becomes a lock-in conversation.

For engineering: It's glue, not a framework. Register the Mercure notifier channel, point it at the hub via DSN, publish. Expect to own the hub deployment, JWT signing for private topics, and a local Docker-based hub for dev/test. Note the ecosystem fit plainly: this is a Symfony Notifier bridge, so it's a straight fit for Symfony services and a deliberate no for Laravel-native notification flows, where we'd use the Mercure client or the Laravel channel instead.

Recommendation: Defer until realtime notifications are an actual roadmap item; adopt then only if the service in question is Symfony/Notifier-based. If it's Laravel, choose the Mercure client or Laravel channel and skip this package entirely. Either way, the 16-star figure should not be the deciding factor — evaluate the parent Symfony Notifier project and, above all, your hub operations story.