Event Source Laravel Package

Product Decisions This Supports

• Build vs. buy for real-time delivery. SSE is the cheaper sibling of WebSockets: one-way server→client push over plain HTTP, no separate socket server, no Redis pub/sub requirement, works through most corporate proxies. This package is a data point in that decision — but a data point that argues against buying, since the "buy" option is a 2017-era library with no maintainer.
• Feature scoping for "live" UX. SSE is the right primitive for: job/export progress bars, in-app notification bells, activity feeds, dashboard counters, deploy/build log tails, and streaming LLM token output. If the roadmap item is "make the import screen show progress," SSE is a 1-day story; WebSockets is a 1-sprint story plus ongoing infra cost.
• Infrastructure cost modeling. The critical PM input is that SSE connections are long-lived. On PHP-FPM, each open stream occupies a worker process — 50 concurrent dashboard viewers can mean 50 pinned workers and a site-wide outage. This package does nothing to solve that (no async runtime, no connection pooling). That single fact reshapes the roadmap: SSE is fine for hundreds of concurrent users with Octane/Swoole or a dedicated lightweight endpoint, and wrong for tens of thousands.
• Vendor and supply-chain risk decisions. Zero stars, zero dependents, last release September 2017, and a -bundle repo name that signals Symfony-first packaging rather than Laravel-native. A PM uses this as the canonical example of "abandoned dependency," feeding a standing rule: no new production dependency without a maintainer, a release in the last 18 months, and a real dependent count.
• Deprecation/upgrade budgeting. Any team that pulled this in during the PHP 7 era now carries an unpatchable dependency across PHP 8.x upgrades. That's a line item in the modernization roadmap, not a footnote.
• Reference-implementation use. The one legitimate product use: read the source to confirm the wire format (Content-Type: text/event-stream, data:/event:/id:/retry: framing, the double-newline terminator) and then write it yourself. It answers "what does SSE actually require on the server?" for free.

When to Consider This Package

Consider it only in these narrow cases:

• You are doing a throwaway spike — a one-afternoon proof that SSE renders in your client before you commit to the protocol. Even then, copy the ~40 lines you need rather than adding the dependency.
• You are on a legacy Symfony app pinned to PHP 7.x, already vendored this bundle, and are explicitly freezing the codebase. In that scenario it is a known quantity rather than a new risk.
• You want a minimal reading reference for the SSE framing spec to validate your own implementation.

Look elsewhere — specifically, write it yourself or use the framework — in every other case:

• Framework mismatch. This is packaged as a -bundle (Symfony convention), not a Laravel package with a service provider and facade. Expect manual wiring, no config publishing, no Laravel-native response helpers.
• No maintenance signal. Last release 2017-09-07; zero stars, zero dependents, no evidence of an active maintainer. No security response path, no PHP 8.x compatibility guarantee, no deprecation coverage.
• Laravel already ships this. Recent Laravel versions include a first-party streamed-response helper for SSE; Symfony has StreamedResponse. You get a maintained, framework-native implementation with zero new dependencies for free.
• Requirements beyond trivial broadcast. Auth on SSE endpoints is genuinely awkward (the browser EventSource API cannot send custom headers, so you're in cookie/query-token territory), and reconnection, last-event-ID resume, and multi-worker fan-out all need application logic this library does not provide.
• Scale or multi-node. You need Redis pub/sub or a message broker to make events reach whichever worker holds the connection. Nothing here addresses that, and the roadmap should budget for it explicitly.
• Proxy/CDN environments. Buffering proxies and some load balancers break SSE unless configured (disable buffering, raise idle timeouts). If you can't control that layer, evaluate polling or WebSockets instead.

How to Pitch It (Stakeholders)

Executives: We evaluated an open-source library for adding live, push-style updates — progress bars on long jobs, notification badges, live dashboards — without building a WebSocket service. The library itself is not adoptable: last shipped in 2017, no maintainers, no users, and built for a different framework. The good news is that the capability is cheap and the framework already provides it. Recommendation: build live updates on the framework's native streaming support, scope the first release to progress indicators and notifications, and budget explicitly for the load-balancer and worker-capacity work that long-lived connections require. Do not add a dependency here; the cost of adopting this one exceeds the cost of writing the ~50 lines it contains.

Engineering: Treat garlic/event-source as a reference document, not a dependency. It confirms SSE is just a text/event-stream response with data: frames and a double newline — which means the real work isn't the protocol, it's the operational envelope: holding PHP workers open, fanning events out across nodes via Redis, handling EventSource's inability to send auth headers, and disabling proxy buffering. Use the framework's streamed-response helper, put the endpoint behind its own route group with a short idle timeout, and load-test with realistic concurrent-connection counts before we ship. If we do a time-boxed spike, vendor nothing — copy the framing logic into a local helper so we own it outright.