Laravel Mercure Broadcaster Laravel Package

Technical Evaluation

What this release is. 3.9.0 is a single-change release: a Laravel 13.x compatibility PR from Laravel Shift. No new features, no config changes, no deprecations, no breaking changes. For planning purposes treat it as a routine forward-compatibility bump — low urgency, but a positive maintenance signal (the maintainer is tracking upstream framework releases promptly).

Architecture fit. mvanduijker/laravel-mercure-broadcaster plugs Mercure into Laravel's existing broadcast abstraction. It registers a mercure broadcast driver so broadcast(new OrderShipped(...)) flows through the same ShouldBroadcast events, channels, and queue plumbing already used for Pusher/Ably/Reverb. That is the package's main TPM-relevant property: it is an adapter, not a platform. It commits us to running a Mercure hub (Caddy with the Mercure module, or FrankenPHP) as an additional stateful service, and it shifts real-time transport from WebSocket to Server-Sent Events over HTTP/2.

Integration feasibility. Server side is close to trivial: publish config, set BROADCAST_CONNECTION=mercure, supply hub URL, public URL, and a JWT secret. The friction is on the client side — Laravel Echo has no first-party Mercure connector, so the front end must use the mercure JS library or raw EventSource plus a private-subscription endpoint that mints subscriber JWTs. That is a bespoke front-end workstream, not a config change, and it is the item most likely to be underestimated.

Technical risk.

• Concentration risk: single-maintainer package with a narrow scope. Mitigated by the fact that the alternative is ~200 lines of custom broadcaster code — we could fork or vendor it if maintenance lapses.
• Coupling to hub version: the broadcaster is thin, but the JWT claim model and topic conventions are defined by the Mercure spec; a hub major upgrade is the more likely breakage vector than a package release.
• Framework churn: Laravel 12→13 timing affects the upgrade window; this release removes that as a blocker but does not establish a support matrix beyond it.
• Auth model: private updates depend on correctly signing JWTs with mercure.subscribe/publish claims. Misconfiguration fails open or closed silently depending on hub config — needs an explicit test.
• Evidence gap: this assessment is based on release metadata only; no dependency audit, CVE scan, or load test has been run.

Key questions for the maintainer/team.

1. Which Laravel and PHP versions are inside our support window at rollout, and does 3.9.0 cover all of them?
2. Who owns the Mercure hub — platform team as a managed service, or application team?
3. Does any product surface genuinely need SSE-over-WebSocket tradeoffs (one-way fan-out, HTTP/2 multiplexing), or is Reverb/Pusher already sufficient?
4. What is the fallback if the package is abandoned — fork, vendor, or replace with an in-house driver?

Integration Approach

Stack fit. Best fit is a Laravel app already broadcasting domain events, with an HTTP/2-capable edge (Caddy, FrankenPHP, or a TLS-terminating proxy that does not buffer text/event-stream). Poor fit if we are on shared hosting, behind an aggressive buffering CDN, or need bidirectional client→server messaging — SSE is one-way by design.

Migration path (from Pusher/Ably/Reverb).

1. Keep the existing driver in place; add mercure as a second connection in config/broadcasting.php.
2. Stand up a non-production hub with a self-signed JWT; validate publish path only (php artisan tinker → dispatch a test event).
3. Build the subscriber side: a /broadcast/auth equivalent that issues scoped subscriber JWTs, plus front-end EventSource wiring. Prototype on one low-risk feature.
4. Cut over per-feature behind a flag, not per-application, so rollback is a config toggle rather than a deploy.

Compatibility notes.

• 3.9.0 is additive; 3.8.x users can upgrade without code changes. Pin ^3.9 and let Composer resolve.
• Confirm the transitive symfony/mercure constraint is compatible with the hub version we deploy — this is the most common source of "works locally, fails in staging."
• JWT secret must be shared symmetrically between app and hub, or configured as an RSA keypair. Decide once; rotating later invalidates live subscriptions.

Sequencing.

• Week 1: spike — hub in Docker, one event end-to-end, measure effort on the front end.
• Week 2: auth design and negative tests (expired token, wrong topic, anonymous subscribe attempt).
• Week 3: pilot feature in staging, load test at expected peak concurrent connections.
• Week 4: production pilot behind flag; document runbook before broad rollout.

Operational Impact

Maintenance. Low code-maintenance load — the package is small and changes rarely, and 3.9.0 shows the maintainer responds to framework releases. The recurring cost is dependency hygiene: bumping the package alongside Laravel majors, and keeping the hub image patched. Budget roughly a half-day per Laravel major plus monthly patch review.

Support model. Two distinct on-call surfaces: (a) the Laravel app, already covered; (b) the Mercure hub, which is new. The hub needs an owner, a health check, log aggregation, and a documented restart procedure. Without that, SSE failures will be triaged against the wrong team.

Scaling characteristics.

• Each subscriber holds an open HTTP/2 connection; memory scales with concurrent connections, not message volume. Capacity planning is a connection count exercise, not a throughput one.
• Caddy-based hubs scale horizontally only with a shared transport for the update bus — plan for a single hub plus vertical headroom first, and treat multi-node as a separate project.
• History/replay requires BoltDB (or similar) and adds disk I/O; without it, reconnecting clients silently miss events between disconnect and reconnect. Decide explicitly whether at-most-once delivery is acceptable.

Failure modes to instrument.

• Hub down → publishes fail; events should degrade to queued retries, not lost dispatches. Verify the broadcaster surfaces errors rather than swallowing them.
• Proxy buffering / idle timeouts → connections drop at 30–60s intervals. Alert on abnormal reconnect rate.
• JWT expiry mid-session → subscribers go quiet with no user-visible error unless the client handles 401 and re-subscribes.
• Queue backlog → broadcasts fire late; separate the broadcast queue from critical jobs.
• Secret rotation → mass subscription invalidation; schedule with a maintenance window.

Ramp-up. Estimate one to two days for a Laravel developer to be productive server-side, and three to five days for the front-end work (EventSource lifecycle, reconnect/backoff, private topic authorization, testing SSE in CI — which is genuinely awkward). Add a half-day of platform onboarding for the hub. The package itself is learnable in an hour; the surrounding protocol and auth model is where the time goes.

Recommendation. Adopt 3.9.0 as the pinned version if Mercure is the chosen real-time path — it clears the Laravel 13 blocker at no cost. Do not treat it as a reason to choose Mercure; that decision rests on whether one-way SSE fan-out, cheap horizontal read scaling, and no per-connection vendor pricing outweigh the cost of running and owning a hub plus custom front-end integration.