sarfraznawaz2005/laravel-sse
A lightweight Laravel package for Server-Sent Events (SSE) that lets you stream real-time updates from your app to the browser without WebSockets, using a simple API for sending events and keeping connections alive.
Architecture fit. sarfraznawaz2005/laravel-sse is a thin, single-purpose Laravel package that adds Server-Sent Events plumbing on top of the framework's streaming response primitives. That is a good architectural fit for one-way server push inside an existing monolith: progress indicators for queued jobs, notification badges, tailing logs or import status, and dashboard refresh. It is explicitly not a WebSocket replacement — there is no bidirectional channel, no channel authentication layer, and no broker. Teams that frame it as "cheap realtime" usually end up rebuilding the missing pieces, so the decision should be scoped to fire-and-forget, per-request event streams where a dropped connection is recoverable by client reconnect.
Integration feasibility. The surface area is small: a Composer dependency, occasionally a published config, and a route/controller that returns a streaming response. There is no database migration, no queue worker, no service container binding a team must learn. Realistic effort for a spike is hours, not days. The dominant cost is not the package but the environment — reverse proxies, PHP-FPM, and load balancers all have opinions about long-lived HTTP responses.
Technical risk. Release 3.0.0 is a major version whose only documented change is raising the illuminate/support constraint to Laravel 12 (PR #11, new contributor). Nothing in the notes describes a feature, deprecation, or API break beyond the framework constraint. That pattern carries two distinct risks. First, it is a hard cutover: applications on Laravel 10 or 11 cannot consume 3.x, and there is no evidence of a compatibility shim or a documented deprecation window. Second, a major bump for a constraint-only change suggests the project applies semver loosely at the major boundary, so downstream teams should not infer "3.0.0 contains breaking API changes" nor "3.0.0 is safely drop-in from 2.3.0" — both need verification by diff. Third, the project is effectively single-maintainer with low release cadence; v3.0.0's only change arriving via an outside contributor is a signal of maintenance-by-issue rather than a roadmap. That is acceptable for a package this small (it wraps framework behavior, so the blast radius of abandonment is bounded and forkability is high) but it should be recorded as a vendor risk, not ignored.
Key questions.
composer.json?Last-Event-ID / retry) handled by the package or left to the client?Stack fit. The package presumes a conventional Laravel HTTP stack — nginx/Apache in front of PHP-FPM, one PHP worker occupied per open stream. It fits an app already on Laravel 12 with no exotic runtime. It fits poorly if the target service runs Octane, sits behind a CDN with aggressive buffering, or terminates at an API gateway with a 30-second idle timeout.
Migration path. Treat 2.3.0 → 3.0.0 as a framework-upgrade gate, not a package upgrade. The real dependency decision is "do we move this service to Laravel 12," and the SSE package is a passenger on that decision. Concretely: (1) diff the two tags to confirm nothing but composer.json moved; (2) pin 2.3.0 on any Laravel ≤11 service and record it as a known-stale pin with an owner; (3) for Laravel 12 services, adopt 3.0.0 directly with no code change expected. Do not attempt to hold a mixed-version fleet on a single SSE version — either the service is on 12 or it stays on 2.3.0.
Compatibility. Verify PHP version floor against our base images before pinning, and confirm the package's route/middleware registration still behaves under the framework's current HTTP kernel conventions. If we publish config or views, re-publish and diff rather than assuming identical defaults. For anything running Octane, test explicitly or exclude the package from those services.
Sequencing. (1) Spike behind the real proxy to validate buffering and timeouts before committing. (2) Ship a single low-stakes stream (job progress on an internal admin screen) with client-side reconnect and a server-side heartbeat. (3) Only after that proves out, expand to user-facing notifications. (4) Reserve capacity — dedicate a small PHP-FPM pool to streaming routes so a spike in open connections cannot starve normal request handling. (5) Wrap the package behind our own thin service class so a future fork or replacement is a one-file change.
Maintenance. Low churn, low ceremony, single maintainer, no migration files or scheduled tasks. The cost is not upkeep but upgrade coupling: the package's version is now welded to the framework's major version, so every Laravel major becomes a forced re-evaluation of this dependency. Budget for that as recurring, not one-off. Because the package is small and wraps documented framework behavior, the fork-and-own contingency is genuinely viable — keep the wrapper boundary so that option stays cheap.
Support. No commercial support, no SLA, and release notes that state the constraint bump without a migration note or changelog narrative. Expect to self-diagnose. That is tolerable for an internal admin feature and much less tolerable for a customer-facing notification channel, so tier the use accordingly.
Scaling. This is the dominant operational characteristic. Each open stream holds a PHP worker for its lifetime; concurrency is bounded by pool size, not by CPU. Ten streaming routes per user across a few hundred users will exhaust a default pool. Mitigations: separate FPM pool with its own pm.max_children, hard server-side cap on stream duration (force close and let the client reconnect), heartbeat comments to keep intermediaries from idling the connection out, disable proxy buffering (X-Accel-Buffering: no or equivalent), and confirm the load balancer's idle timeout is longer than the heartbeat interval. Scaling path is horizontal (more workers) until it isn't — at which point the correct answer is a real pub/sub + WebSocket layer, not more SSE.
Failure modes. Silent buffering by a proxy (client sees nothing until the stream ends, or never); idle-timeout disconnects behind gateways and CDNs; PHP worker exhaustion cascading into unrelated 502s; unbounded loops in the event handler leaking memory until the worker is killed; reconnect storms when many clients retry in lockstep after a deploy or blip — mitigate with jittered client backoff; and auth expiry mid-stream, since a long-lived response can outlive the session that authorized it. Each needs an explicit owner and a detection signal, not just a hope.
Ramp-up. Developers pick up the package in an afternoon; the learning curve is SSE-as-a-protocol and the surrounding infrastructure, not the PHP. Plan for the team to understand event framing, Content-Type: text/event-stream, cache-disabling headers, heartbeat semantics, and reconnect behavior before shipping anything user-facing. Add a runbook entry covering "streams stop arriving" and "worker pool saturated" so on-call does not debug this from first principles at 3am.
How can I help you explore Laravel packages today?