Lighthouse Ws Laravel Package

Product Decisions This Supports

• Real-time feature feasibility. The package proves out a shape of product capability we may want regardless of whether we adopt it: schema-declared subscription fields that push live updates to Apollo/graphql-ws clients, authorized per-user via Laravel guards, over a pluggable broadcast transport (Reverb, Pusher, Redis). That is the technical envelope for notifications, live dashboards, presence, chat, collaborative editing, and long-running job/import status — the usual candidates on a roadmap.
• Build vs. buy vs. adopt. The verdict this package drives is "don't adopt, do build." It is archived, last released in May 2018, and carries 12 stars — no maintenance, no security patching, no upgrade path. But the capability it was built to provide has since landed in first-party Laravel tooling (Lighthouse's own subscription support plus Laravel Reverb as a first-class WebSocket server). So the PM decision is not "real-time or nothing"; it's "real-time via core, with this repo as a design reference only."
• Roadmap sequencing and scope. Real-time is an additive layer on an existing GraphQL API, not a re-platforming effort. It should be scoped as a timeboxed spike plus one bounded user-facing surface, gated on a named product requirement (e.g. "notifications appear within 2s without refresh"), not scheduled speculatively.
• Platform standardization. Choosing one WebSocket transport for the org — Reverb if we're Laravel-first — is a decision this package surfaces. Fragmented transports (Pusher here, a Node socket service there) create recurring operational and cost overhead.
• Defer / kill criteria. If no surface on the roadmap has a stated latency requirement that polling or short-interval refetch can't meet, real-time subscriptions are a "no" for the next two quarters. Recording that explicitly prevents re-litigating it.

When to Consider This Package

Consider it only in these narrow cases:

• As a reference implementation, not a dependency — reading it to understand the @subscription directive pattern, channel naming, payload serialization, and guard-based authorization before building the equivalent on maintained foundations.
• You are on Lighthouse and evaluating subscription approaches, and need a concrete comparison point for what core support now gives you.
• You have a genuine in-house owner willing to vendor or fork an archived repo and accept full maintenance and security responsibility. This is defensible only for internal, non-revenue tooling.

Look elsewhere — decisively — when:

• Anything touches production or a revenue path. An archived dependency with an eight-year-old last release is a standing upgrade and CVE liability.
• You want the same features with support. Lighthouse's built-in subscription support with Reverb (or Pusher/Redis) delivers the described capability set without the abandonment risk; that is the default recommendation.
• Your stack isn't Laravel-first. Outside a full Laravel runtime, the framework coupling is cost without leverage — use a dedicated graphql-ws server or plain Laravel broadcasting with Echo instead.
• You need scale guarantees, SLAs, or a security disclosure path. None exist here.

How to Pitch It (Stakeholders)

To executives: Real-time capability is worth having and is achievable without adding risk. The specific package we evaluated is archived and unmaintained, so we are not recommending adoption — we are recommending the same outcome on first-party Laravel tooling (Lighthouse subscriptions + Reverb). Ask: endorse standardizing on Reverb as our WebSocket transport and approve a short, timeboxed spike scoped to one user-facing surface.

To engineering: Mechanically this is composer require plus config — the real cost is ownership. Adopting an archived package means we become its maintainers, absorb security patching, and lose upgrade guidance. The capability set is well understood (declarative subscription fields, pluggable broadcast drivers, guard-based auth, graphql-ws/Apollo compatibility), so replicating it on core is low-uncertainty work. Deliverable: a one-week spike demonstrating one subscription end-to-end, with a written decision record covering transport choice, pinning policy, and rollback.

Framing line for the room: The idea is right, the package is not. We get the feature by building on what we already maintain.