Chattle Laravel Package

Technical Evaluation

Architecture fit. This release is not a feature addition — it is a hard compatibility pin. The package is a repackaging/fork of beyondcode/laravel-websockets, an archived upstream, and v2.0.0 constrains the framework to Laravel 10 only. Architecturally it remains what upstream was: a self-hosted, Pusher-protocol-compatible WebSocket server that plugs into Laravel's broadcasting system and is consumed by Laravel Echo on the client. It fits Laravel 10 applications that need private/presence channels without a managed Pusher subscription, and fits cleanly only in that envelope.

Integration feasibility. Mechanically straightforward inside a Laravel 10 app: composer require, publish config and migrations, run websockets:serve under a process supervisor, and point the pusher broadcast driver at the local host/port. Channel authorization continues to route through the app's routes/channels.php. The friction is not integration effort — it is that the constraint is exclusionary. Any application on Laravel 11 or 12 cannot install this at all, and any application planning an upgrade is blocked at dependency resolution time.

Technical risk. High, for reasons that go beyond the code:

• Upstream is archived. The package inherits an unmaintained dependency tree (Ratchet, React, and their transitive PHP/socket libraries). The fork can pin Laravel, but it also absorbs responsibility for every future CVE in that tree.
• A major version bump to express a version pin signals that the constraint is structural, not incidental. It suggests the maintainer hit a genuine incompatibility with Laravel 11+ rather than choosing conservatism.
• Framework version pinning is an anti-pattern for infrastructure packages. It converts a routine composer update into a planned migration, and it will conflict with any other dependency requiring a newer framework.
• No stated Laravel 11/12 roadmap. Without one, this should be treated as a bridge, not a destination.

Key questions.

1. Who maintains this fork, and what is the stated commitment window and CVE response expectation?
2. Is the Laravel constraint enforced via require or conflict, and is there a provide/replace relationship with the archived upstream?
3. Is the Pusher wire protocol and Echo client compatibility unchanged from upstream, or are there behavioral deltas?
4. What is the supported PHP matrix, and does it include 8.3/8.4?
5. Is there CI, a test suite, and a documented diff against the last upstream release?
6. Is there an explicit migration recommendation (Laravel Reverb, Soketi, or managed Pusher)?

Integration Approach

Stack fit. Narrow and explicit: Laravel 10, PHP 8.1–8.3, Laravel Echo clients, Redis for horizontal fan-out. If the estate is not already on Laravel 10, this package is not a candidate and the evaluation ends there.

Migration path. Adopt with a defined exit. The natural destination is Laravel Reverb — the first-party WebSocket server introduced with Laravel 11 — which speaks the same Pusher protocol and preserves the Echo client contract. Soketi is the alternative if the application stays on Laravel 10 longer term. Both allow a client-side-near-zero migration if broadcasting is kept behind Laravel's Broadcast facade and channel authorization stays in routes/channels.php.

Compatibility. The pin is the dominant constraint. Verify early that no other dependency in the lockfile requires Laravel 11+; if one does, the package is unusable regardless of intent. Also confirm the package's config schema and migration names don't collide with a prior beyondcode/laravel-websockets install, since both may register the same tables and publish tags.

Sequencing.

1. Inventory: confirm framework version, current broadcasting driver, and whether beyondcode/laravel-websockets is already present (in which case this is a replacement, not an addition — plan the composer swap and table/config reconciliation).
2. Bound the commitment: adopt only with a written decision that the application will not need Laravel 11 for the duration, or with a migration ticket opened at the same time.
3. Isolate: ensure no application code references the package directly — only the Broadcast facade, the pusher driver config, and channels.php. This makes step 5 a config change.
4. Operate: supervisor/systemd unit for websockets:serve, health check, log shipping, Redis for multi-node.
5. Exit: migrate to Reverb (or Soketi) and remove the package and its migrations.

Operational Impact

Maintenance. The team inherits the maintenance of an archived project's runtime. Budget for periodic review of the Ratchet/React dependency chain, PHP minor-version compatibility, and security advisories — none of which will be handled upstream. Treat the package as internally-owned infrastructure, not a vendor dependency.

Support. Community-only. There is no vendor SLA, no commercial backstop, and the maintainer of the pin may be a single individual. Escalation for a production WebSocket outage is internal.

Scaling. Unchanged from upstream: single-node is simple; horizontal scaling requires a Redis pub/sub adapter for cross-node message fan-out, sticky sessions or a shared handshake strategy at the load balancer, and separate capacity planning for long-lived connections (which behave very differently from request/response traffic under autoscaling — connection draining and rolling deploys need explicit handling). This is the highest-effort operational area and is independent of the Laravel pin.

Failure modes.

• Composer resolution failure the moment any dependency requires Laravel 11+ — silent until CI breaks.
• PHP runtime incompatibility after an unattended base-image bump.
• WebSocket process death under memory pressure, mitigated only by the supervisor.
• Protocol or config drift during a future framework migration if the exit path was not exercised.
• Config/migration collision when replacing an existing beyondcode/laravel-websockets install.

Ramp-up. Low for developers — the Echo and broadcasting APIs are familiar and well documented. Moderate for operations — the long-lived-connection model, Redis fan-out, and supervisor-based process management are a different operational shape from stateless PHP-FPM, and should be owned by someone with real-time infrastructure experience.

Recommendation. Approve only as an explicitly time-boxed bridge for Laravel 10 applications that already depend on this capability, with a migration ticket to Reverb or Soketi opened at adoption. Do not adopt as a greenfield choice, and do not treat the v2.0.0 pin as evidence of active forward development.