Laravel Lighthouse Graphql Multi Schema Laravel Package

Technical Evaluation

Architecture fit The package targets a real structural gap rather than a cosmetic one. Lighthouse is effectively single-schema by design: one schema_path, one route, one middleware stack, driven from a singleton manager. Any team serving distinct API surfaces (public/mobile, admin, partner, internal tooling) from one Laravel deploy ends up hand-rolling per-schema bootstrapping. A package that formalizes named schemas — each with its own schema file, route/middleware, resolver namespaces, and likely its own config block — fits cleanly into Laravel's package conventions (auto-discovered service provider, publishable config, route registration). Conceptually it is the right abstraction at the right layer.

Integration feasibility Low lift in a greenfield or modular-monolith context: composer require, publish config, declare schemas, done. The work is not installation but verification. Because the package must wrap Lighthouse internals (LighthouseManager, GraphQL facade, SchemaBuilder, schema cache), the integration surface is small but sits against an API Lighthouse does not contractually stabilize. Composer constraints on nuwave/lighthouse and laravel/framework are the first thing to read — they determine whether this is a drop-in or a fork-from-day-one.

Technical risk

• Vendor coupling to internals. Multi-schema necessarily means either multiple manager instances or runtime config swapping. Both are sensitive to Lighthouse major-version changes (5→6 reworked directive and schema-loading internals). Breakage will surface as runtime fatals, not static errors.
• Schema/AST cache keying. Lighthouse caches parsed schemas. If the cache key is not schema-scoped, you get cross-schema contamination — a correctness bug that can leak admin types onto a public endpoint. Highest-severity item to test.
• Isolation of auth and middleware. Per-schema guards, throttles, complexity/depth limits, and introspection gating must be independently configurable. A shared default is an auth-bypass vector, not a convenience.
• Octane/queue safety. Config mutation per request is the classic Laravel singleton-state hazard. Must be proven safe under Octane.
• Maintenance signal. 16 stars, zero dependents, single maintainer, no downstream evidence of production use. The 2026-10-15 release date also warrants a look at tag provenance and Packagist integrity before trusting version metadata.
• Test posture. Unknown CI matrix. Ask for Laravel 10/11/12 × PHP 8.2/8.3 coverage and at least one test asserting route→schema→middleware resolution.

Key questions

1. Which Lighthouse and Laravel versions are supported, and is there a SemVer/deprecation policy?
2. Does it register routes automatically, or does it expose a manager the app wires itself?
3. Is each schema fully isolated for middleware, guards, validation rules, complexity limits, and introspection?
4. How is the schema cache keyed, and does lighthouse:cache handle all schemas in one pass?
5. Is this isolation only, or does it claim stitching/federation (materially different risk profile)?
6. Who owns maintenance, and what is the stated support commitment?

Integration Approach

Stack fit Laravel 10–12, PHP 8.2+, Lighthouse 6.x. Composer-native, zero infrastructure. It suits a modular monolith or a BFF serving several client classes better than it suits microservices — the value is one deploy, many contracts, shared domain code.

Migration path Incremental and reversible. Leave the existing single schema on the current route, introduce the second schema on a new URI, and move one consumer at a time. Start with a low-blast-radius surface — internal tooling or admin — so a failure is contained. The critical property for a TPM: the pattern is reimplementable in-house in a few hundred lines against Lighthouse's public SchemaBuilder/manager surface. Lock-in is therefore low, which cuts both ways — cheap to adopt, cheap to leave, and not much durable moat for the package.

Compatibility Verify explicitly against co-installed packages rather than assuming: Sanctum (per-schema guard resolution), Telescope (route/query attribution per schema), Horizon, Octane, and Lighthouse's own caching and validation directives. The middleware stack and route registration behavior are the two areas that have historically shifted across Lighthouse majors.

Sequencing

1. Spike (1–2 days). Install in a branch, define two schemas, confirm route registration, middleware, and guard isolation end-to-end.
2. Isolation tests as a gate. Assert an admin-schema endpoint rejects a public token, and that a public endpoint cannot resolve admin-only types — including after cache warm.
3. Cache + Octane validation. Run lighthouse:cache, then exercise both schemas; repeat under Octane with interleaved requests.
4. Load and complexity check. Confirm per-schema depth/complexity limits actually apply per schema.
5. Consumer migration. Move one real client, observe for a release cycle, then expand.
6. Contingency. Budget the fork up front: vendor a pinned copy or maintain a patch set. MIT makes this trivial; the cost is ownership, not licensing.

Operational Impact

Maintenance Assume you own it. Pin the version, review the diff on every Lighthouse upgrade, and designate a named engineer as package owner. Keep a fork-ready copy in private VCS. The realistic ongoing cost is small — a few hours per Lighthouse major — but it is not zero, and it lands on whoever owns the GraphQL layer.

Support Effectively none. No dependents means no de facto community and no externally proven runbooks. Do not plan on upstream responsiveness; plan on internal resolution.

Scaling The scaling profile is Lighthouse's, not this package's: N+1 resolution without batching, query depth/complexity enforcement, persisted queries. What this package adds is that those controls must be configured per schema rather than once — an easy thing to under-specify. Memory overhead for multiple parsed ASTs is negligible; warm the cache at deploy.

Failure modes

• Schema confusion — a route resolving the wrong schema after a config merge.
• Config drift — a new Lighthouse config key added upstream and mirrored to only one schema block.
• Cache contamination — the highest-severity failure; treat as an auth issue, not a bug.
• Auth bypass via mounting — an admin schema accidentally attached to a public route.
• Silent abandonment — upstream goes quiet; you discover it during a Laravel upgrade.

Ramp-up Half a day for a developer already fluent in Lighthouse; the mental model is just "N schemas instead of one." Budget more for the person who has to understand Lighthouse internals to fork it — that is the real knowledge concentration risk, and it argues for documenting the in-house reimplementation path alongside the package.

TPM recommendation: adopt behind a spike-and-gate, restricted initially to a non-public schema, with isolation tests and the fork contingency costed in. It solves a genuine problem cheaply; it does not come with the maintenance assurances that would justify putting a public-facing contract on it without verification.