Lighthouse Ws Laravel Package

Technical Evaluation

Verdict up front: this is an archived package, last released 2018-05-05, with 12 stars. It predates every current component named in its own description. A TPM should treat it as prior art to read, not a dependency to ship.

Architecture fit Where it fits is genuinely Laravel: it targets Lighthouse (the GraphQL framework for Laravel) and hooks Lighthouse's @subscription directive into Laravel's broadcasting layer. Conceptually that is the right shape — schema-declared subscriptions, broadcast driver behind it, guard-based auth for private channels. The design is aligned with how a Laravel GraphQL service should do realtime.

The artifact is not aligned with any stack we would run today. A 2018 release implies a PHP 7.0–7.2 floor, Laravel 5.5/5.6-era contracts, and a Lighthouse major version several generations back. Its dependency constraints will almost certainly refuse to resolve against PHP 8.2+, Laravel 11/12, and Lighthouse 6.x. That is a hard blocker, not a friction point.

Note the description/reality mismatch: it advertises Reverb as a supported driver. Reverb did not exist in 2018. Either the description is retrofitted marketing copy or the package has been silently modified — both are reasons to distrust the stated feature set. Verifying that discrepancy is the first thing a spike would do, and it is also the reason not to fund the spike.

Integration feasibility Mechanically it would be composer require, provider discovery, config publish — the usual ten-minute Laravel install. The real cost is that nothing else works after that. Making it run means pinning the host application to an EOL PHP line and an old Laravel major, which cascades into security patching, CI images, and every other dependency in the lockfile. We would be downgrading the platform to accommodate a 12-star archived package. That trade is not available to us.

If we already have it installed somewhere, feasibility flips to "how fast can we remove it" — see the migration path below.

Technical risk

• Abandonment (certain, not probable). Archived means no security patches, no PHP 8 support, no framework-major compatibility, and no issue responses. Risk is realised on day one.
• Protocol drift (high). 2018-era WebSocket GraphQL meant Apollo's subscriptions-transport-ws (start/data/stop frames). Modern clients speak graphql-transport-ws (subscribe/next/complete, plus ping/pong). The "compatible with graphql-ws / Apollo clients" claim is very likely false against current clients, and the failure is silent — connections establish, nothing is delivered.
• Superseded by core (high). Subscription support has since moved into Lighthouse itself, and the WebSocket serving layer it depended on (laravel-websockets) has been superseded by Reverb. The package's reason to exist has been absorbed upstream.
• Description accuracy (medium). Driver and client claims cannot be verified from the artifact; see above.
• Supply chain (medium). Unmaintained transitive dependencies (Pusher SDK, websocket libs) with no upstream fix path for a future CVE.

Key questions

• Do we have any service today with nuwave/lighthouse-ws in composer.json or composer.lock? That single fact determines whether this is an evaluation or a remediation.
• Does our current Lighthouse version ship @subscription support natively, and does it cover our intended use cases (public broadcast, private authenticated, filtered payloads)?
• Which client protocol do our front-ends actually implement — graphql-transport-ws or the legacy subscriptions-transport-ws?
• Which broadcast backend is sanctioned for us: self-hosted Reverb, Redis pub/sub, or Pusher SaaS? The SaaS route carries procurement, data-residency, and per-connection cost implications.
• Do we need per-subscription authorisation (guard-based private channels), and does that map onto Sanctum/token auth in our app?
• Is there any custom patch in the archived source we would lose by switching to core?

Integration Approach

Stack fit Target: Laravel 11/12, PHP 8.2+, Lighthouse current major, Reverb as the WebSocket server. That is the supported path and it does not involve this package. The package only fits a frozen 2018 stack, which we should decline.

Migration path Net-new adoption of the capability, not of the package. If an existing service already depends on lighthouse-ws, invert this into a remediation plan:

1. Inventory: confirm via lockfile and composer why whether it is a direct or transitive dependency.
2. Confirm the Lighthouse core subscription surface covers the existing schema fields and auth rules.
3. Stand up Reverb alongside; run both endpoints behind the same client-facing path if possible.
4. Cut clients over per subscription field, then remove the package and any tables/config it published.

Compatibility Three axes, all currently failing on this package: PHP floor, Laravel major, and Lighthouse major. On the replacement path the axes are: Lighthouse version vs. Reverb version, Reverb vs. our Redis version, client subprotocol vs. server subprotocol, and broadcast auth middleware vs. our token strategy. Pin Reverb and Lighthouse explicitly; do not use caret ranges across a major boundary.

Sequencing

• Day 1–2: confirm inventory (is it installed anywhere?) and confirm Lighthouse core covers the feature set. This resolves most of the decision.
• Week 1: if replacing an existing use, spike core subscriptions + Reverb on one schema field behind a flag.
• Week 2: client protocol validation against a real front-end; failure here is the one that survives to production.
• Week 3: full cutover or, for net-new work, expand to the intended scope.
• Ongoing: no work on this package. Do not add it to any backlog item labelled "integration."

If a team insists the archived source has a design worth borrowing, timebox two engineer-days to read it as an RFC input. That is the only leverage it offers.

Operational Impact

Maintenance Zero upstream maintenance, and that is the whole story: no patches, no PHP 8 support, no fixes for framework breakage. If we adopted it we would own a fork permanently, which for a 12-star archived project means we are the maintainers of record. On the replacement path, maintenance is normal Laravel dependency hygiene plus Reverb version tracking.

Support None. The repository is archived, so the escalation path terminates in our own team with no possibility of upstream assistance. Even at 12 stars there was never a community to lean on. Do not place this anywhere near a revenue path.

Scaling The package itself is thin — it is a bridge between Lighthouse and the broadcaster — so the scaling story is the broadcaster's, not the package's. That story is real work regardless of which path we take: persistent WebSocket connections pin to a node, so horizontal scale requires a shared pub/sub backend (Redis) and attention to connection limits, memory per connection, load-balancer idle timeouts, and observability for long-lived sockets. Assume our current monitoring is request-scoped and does not cover connection counts or subscription delivery latency. Budget for that instrumentation as part of the capability, not the package.

Failure modes

• Platform lockout (highest impact): adopting it forces an EOL PHP/Laravel pin, blocking security upgrades across the whole application.
• Silent delivery failure: client subprotocol mismatch — handshake succeeds, no events arrive, no error surfaces. Mitigate with an end-to-end assertion on delivery, not on connection.
• Unpatchable CVE: a flaw in an abandoned transitive websocket/Pusher dependency with no upstream fix.
• Description-driven infrastructure bet: choosing Reverb on the strength of a 2018 package's claim that it supports Reverb.
• Connection-pinning surprises: horizontal scale without Redis fan-out, or with config:cache enabled in production but not locally, producing provider-boot or config-resolution differences that never appear in dev.
• Half-migrated state: package removed, published config/tables left behind, confusing later operators.

Ramp-up Low for a Laravel-fluent engineer on the replacement path — a day to a working subscription on Reverb. The genuine ramp-up is organisational: realtime introduces an operational tier we may not run today (WebSocket server lifecycle, Redis pub/sub, connection observability, capacity planning), and someone must own it. Recommend a short decision record at close: capability owner, pinned versions for Lighthouse/Reverb, sanctioned broadcast backend, client subprotocol standard, and an explicit line stating this package was evaluated and rejected as archived.