Lighthouse Laravel Package

Product Decisions This Supports

• Build vs. buy for a GraphQL API layer. Lighthouse is a schema-first GraphQL server bolted directly onto Laravel. The "build" alternative is hand-rolling resolvers on top of webonyx/graphql-php plus your own pagination, filtering, auth, and nested-mutation plumbing. Lighthouse converts most of that into declarative schema directives (@paginate, @whereConditions, @can, @hasManyThrough, @lazyLoad), so the buy decision mostly reduces to "how much of our API surface is CRUD-shaped?" If it is, the payback is fast.
• Roadmap sequencing for API surface. Because the schema is the contract, the PM can sequence GraphQL types and fields as shippable increments without waiting on resolver engineering. Feature flags are first-class (@hide/@show/@feature, usable on types, arguments, and input types since v6.46), which means you can ship schema for a future capability and dark-launch it to a subset of consumers or environments.
• Client-facing capability bets that are otherwise expensive. Nested mutations with @upsert/@upsertMany, @bind (route-model-binding analogue), and @can authorization let you promise mobile/web clients "one round trip, atomic writes" — a genuine product differentiator versus chatty REST. The SaveAwareArgResolver interface and nested-mutation fixes in v6.69.x indicate this path is actively hardened, not decorative.
• Performance and cost-line decisions. File-based query cache leveraging OPcache (v6.63), query-validation result caching (v6.45), Automatic Persisted Queries, and query complexity exposed in lifecycle events give you levers for latency SLOs and for protecting the API from abusive queries. Complexity scoring is a product decision as much as an infra one: it's how you set rate-limit tiers.
• Real-time product features. Subscriptions with Laravel Reverb, Redis, and encrypted subscription channels mean "live presence," "notifications," and "collaborative editing" move from separate-service to in-app scope.
• Observability and B2B/SLA commitments. Apollo-style federated tracing (reports.proto, client-awareness contexts, operation_id in query metadata) supports per-operation reporting — useful if you sell API access and need usage metering or per-tenant dashboards.
• Hiring and velocity decisions. PHP/Laravel is likely already the team's core competency. Choosing Lighthouse keeps the API in the same language, test suite (PHPUnit 12 support, MocksResolvers), and deployment pipeline as the rest of the app — reducing the marginal headcount needed to run an API program.

When to Consider This Package

Adopt when most of these hold:

• The backend is Laravel (or Lumen, though Lumen support is deprecated as of v6.62) and will remain so for the planning horizon.
• Your API is predominantly entity CRUD with relations — the directive set maps cleanly to Eloquent models.
• You want schema-first contract definition where the .graphql file is the source of truth, reviewable in PRs, and usable to generate client types via lighthouse:ide-helper.
• You need GraphQL, not just "a flexible REST API" — the strongest case is multiple heterogeneous clients (web, iOS, Android, partner integrations) with divergent data needs.
• You are on a supported Laravel version; Lighthouse has shipped explicit support for Laravel 12 and 13 (v6.54, v6.66), so it tracks the framework rather than lagging it.
• You want nested mutations and subscriptions without standing up a Node/Apollo subgraph.

Look elsewhere or pause when:

• Governance risk tolerance is low. The README states the repository is planned to move to spawnia/lighthouse (discussion #2767). This is a maintainer-continuity and package-name migration event. Composer package renames mean changelog, security advisories, and dependency-tracking tooling all change URLs. Mitigate by pinning a known-good minor and assigning an owner to track the migration before committing to a multi-year contract.
• The "Dependents: 0" signal is unresolved. For a 3.5k-star package with an active release cadence, a zero dependent count is almost certainly a measurement artifact rather than reality. Do not let it drive the decision in either direction — verify adoption via Packagist install stats and your own network before citing ecosystem risk to stakeholders.
• You need graph-federation across polyglot services as the primary architecture. Lighthouse has federated tracing and subscription support, but if your org strategy is Apollo Federation with Node subgraphs, Lighthouse becomes a partial fit at best.
• The team has no PHP depth, or the platform roadmap is a migration off Laravel. The package's value is inseparable from the framework; a framework migration turns this into throwaway work.
• You need schema-first with heavy custom business logic in every resolver. Directive-driven design shines on convention; if 80% of fields need bespoke orchestration, you are paying the abstraction tax without the leverage.
• You require commercial support with SLAs. MIT-licensed, sponsor-funded maintenance (GitHub Sponsors / Patreon). Budget for either a sponsorship line or internal ownership of upgrade work — SemVer with a single supported major means major upgrades are periodic, planned projects, not background chores.

How to Pitch It (Stakeholders)

One-liner for executives: Lighthouse is a mature, MIT-licensed GraphQL framework that turns our Laravel models into a typed API through schema directives, letting us ship client-facing API features in days instead of sprints while staying inside the stack we already run and hire for.

The business case:

• Speed to market. Schema-first means product defines the contract and engineering implements against it. Pagination, filtering, authorization, relation loading, and nested writes arrive as configuration rather than custom code — a direct reduction in API backlog cycle time.
• Cost avoidance. No second runtime, no separate GraphQL service, no duplicated auth or deployment tooling. We extend the app and pipeline we already operate and monitor.
• Product optionality. Built-in feature flags, query complexity scoring, persisted queries, and subscriptions mean capabilities we would otherwise defer — safe dark launches, rate-limit tiers, real-time features, partner-facing usage reporting — are already in the box.
• Risk profile is manageable and specific. The codebase is actively maintained (frequent 6.x releases, current Laravel 12/13 support, an upgrade guide and changelog discipline, @api-marked stability boundary). The two risks to name honestly are the planned repository move to spawnia/lighthouse and the absence of commercial SLAs — both mitigated by pinning versions, sponsoring maintainers, and naming an internal owner for upgrades.

What we are asking for: Engineering sign-off on Lighthouse as the GraphQL layer, a pinned minor version with a documented upgrade cadence tied to Laravel majors, a modest maintainer sponsorship, and a named owner to track the repository migration and confirm the package name we standardize on before we publish it in our internal platform docs.