p2/ratchet-bundle
A Symfony bundle that integrates the Ratchet WebSocket library, helping PHP developers add real-time, bidirectional communication to applications. It provides configuration and integration points for running WebSocket servers alongside Symfony.
Architecture fit. The package is a Symfony bundle (p2/ratchet-bundle), not a Laravel package. That distinction is the single most important fact for this evaluation: Symfony bundles rely on FrameworkBundle discovery, Extension classes, compiler passes, and tagged service wiring that Laravel's service container does not consume. There is no ServiceProvider, no publishes() migration/config hooks, and no facade — the standard Laravel integration surface is absent. Architectural fit against a Laravel codebase is therefore poor at the packaging layer, even though the underlying runtime (Ratchet) is framework-agnostic and could in principle be driven from an artisan command.
Integration feasibility. Two paths exist. (a) Use the bundle inside a Symfony application it was actually written for — viable only if the target stack is Symfony and the bundle's declared Symfony/PHP constraints are satisfied. (b) Use it inside Laravel — in which case the bundle wrapper is effectively dead weight and the real work is writing a custom artisan websocket:serve command that boots a Ratchet server, wires a message component, and manages the event loop. Path (b) is feasible but means you are adopting Ratchet, not this package; the package contributes little beyond a reference implementation of the wiring.
Technical risk. High, on several independent axes: 26 stars and zero dependents means no ecosystem validation, no downstream projects exercising it in production, and no community triage of edge cases. The repository name style and bundle conventions indicate an older Symfony generation (Symfony 2/3 era), which almost certainly pins PHP and symfony/* versions below what a modern Laravel app runs. Ratchet itself has been in low-maintenance mode for years; PHP 8.x compatibility, ReactPHP version alignment, and TLS/proxy handling all become your team's problem. MIT license is the one unambiguous positive — no legal review friction, forking is permitted. Net: this is a reference artifact, not a dependency to install.
Key questions. Which Symfony and PHP versions does composer.json actually constrain, and does it install at all under our PHP version? Does the bundle expose authentication hooks (session/cookie handoff), or does it assume an unauthenticated socket? What is the actual commit history and last-release date? Which Ratchet and ReactPHP majors does it pin, and are those still receiving security patches? Is there an existing internal Symfony service where this could run natively, separate from the Laravel app?
Stack fit. Poor as a direct dependency in a Laravel monolith. Laravel's first-party options — Laravel Reverb (first-party, WebSocket-native), Laravel Echo with Soketi or Pusher-protocol services, or beyondcode/laravel-websockets (now legacy, Pusher-protocol, itself unmaintained) — cover the same problem with supported tooling, documented auth handoff, and horizontal-scaling patterns. Recommending this bundle over any of those requires a specific justification that is not present in its metrics.
Migration path. If Ratchet specifically is a hard requirement (e.g., an existing Ratchet protocol or binary framing contract), the correct move is to vendor the concepts, not the bundle: read the bundle's server bootstrap and message-component wiring, reimplement it as a Laravel artisan command with a Ratchet\App or IoServer instantiation, and register it under supervisor. Treat the repository as documentation. If Ratchet is not a hard requirement, skip straight to Reverb and avoid the migration entirely.
Compatibility. Expect friction at three points: Composer resolution against modern symfony/* and PHP 8.x; the absence of PSR-4 autoloading conventions expected by current tooling; and no support for Laravel's config/env model, meaning any credentials, ports, and TLS paths get hardcoded or hand-rolled. None of these are blockers, but each is unbudgeted work if the bundle is assumed installable.
Sequencing. 1) Timebox a spike: attempt composer require in an isolated branch, record the exact resolver failures. 2) Decide Ratchet-vs-Reverb on functional grounds (protocol needs, binary support, auth model), not on this package's availability. 3) If Ratchet wins, build the artisan command wrapper and a supervised process definition, with a written protocol contract. 4) Pilot one feature (presence or a single notification channel) behind a flag before broadening. 5) Decide on deprecation of the pilot path once scaling requirements are known.
Maintenance. Effectively sole-maintainer abandoned. Zero dependents means nobody else is filing or fixing issues; you inherit the entire maintenance surface for both the bundle and its pinned Ratchet/ReactPHP versions. Budget for a fork within twelve months if adopted — MIT makes that legal, but it does not make it cheap.
Support. No vendor, no community, no SLA. Internal support means one or two engineers who understand the event-loop model become single points of failure. Documentation will have to be written, not read.
Scaling. This is the sharpest operational constraint. A Ratchet server is a single-process, single-threaded event loop; you scale vertically until you can't, then you need a pub/sub fan-out layer (Redis) plus a sticky-session or connection-registry strategy, and there is nothing in this bundle that provides any of those pieces. By contrast, Reverb and Soketi ship with documented horizontal-scaling stories. Any capacity plan built on this package is a capacity plan the team writes from scratch.
Failure modes. Silent connection drops with no reconnect contract; memory growth in long-lived loops without restart discipline; supervisor misconfiguration producing crash loops that look like client bugs; auth handoff drift between the HTTP session and the socket handshake, which presents as intermittent "works for me" defects; and TLS termination issues behind a load balancer where wss:// is terminated upstream and the server is unaware. Each of these is a known, solvable WebSocket problem — but each is being solved here without a support community behind it.
Ramp-up. For an engineer fluent in ReactPHP's event loop and WebSocket handshake semantics: one to two weeks to a competent pilot. For a team without that background: four to six weeks including the auth handoff and supervisor/observability work, plus ongoing cost of the bus factor. The package itself saves perhaps a day of wiring study — which is the entirety of its technical value.
Recommendation. Do not adopt as a dependency. Retain as a reading reference for Ratchet bootstrap patterns, and select Laravel Reverb as the production path unless a documented protocol requirement forces Ratchet. The 26-star, zero-dependent, low-score profile is consistent with an abandoned package, and the Symfony-versus-Laravel mismatch means the integration cost is paid regardless of whether the bundle installs.
How can I help you explore Laravel packages today?