Laravel Graphql Voyager Laravel Package

Product Decisions This Supports

• Developer documentation: build vs. buy. The package is a thin Laravel wrapper that serves the GraphQL Voyager single-page app against your schema endpoint. The alternative is a custom route plus a static asset bundle — roughly a day of work plus indefinite ownership. Adopting this is a convenience purchase, not a capability purchase; justify it by the cost of maintaining an in-house explorer, not by features the package uniquely provides.
• Internal DX investment and onboarding cost. An interactive type/field/relationship graph collapses the "how is this API shaped?" question that otherwise consumes senior-engineer time in onboarding, code review, and support triage. If your onboarding docs are a hand-maintained schema page that drifts, this is a candidate replacement at near-zero build cost.
• API contract review before breaking changes. The graph view makes coupling, orphaned types, and overly deep relationship chains visible in a way SDL files do not. Useful as an input to deprecation planning and versioning decisions — a review artifact, not a governance system.
• Exposure and access policy. Because the viewer is gated by middleware and authorization, adopting it forces an explicit decision: is the full schema visible to all authenticated engineers, to a subset, or not at all? That decision is the real product question; the package just makes it concrete.
• Scope discipline. This is internal tooling. It should not appear on a customer-facing roadmap, should not drive a Lighthouse adoption decision (if you are not already on Laravel + Lighthouse, this package is not a reason to move), and should be treated as dev/staging-first by default.
• Dependency portfolio hygiene. Five stars and a single recent release is a small footprint. Approve it as a scoped, easily-removable tool — one route, publishable config — not as load-bearing infrastructure. Removing it costs an afternoon, which is the strongest argument for trying it.

When to Consider This Package

Consider it when:

• You run a Laravel + Lighthouse GraphQL API of nontrivial size, and engineers, support, or partner-integration teams repeatedly ask how types relate.
• You want configuration control without a frontend build step: configurable endpoint, route path, middleware, and authorization, with publishable config and assets.
• You want a low-commitment, MIT-licensed internal tool that can be gated to non-production or to authenticated staff, and removed cheaply if it disappoints.
• You are on, or moving to, Laravel 11 — v2.3.0 declares support, though "declared" is not "tested"; confirm CI coverage and whether the Composer constraint is additive (^10|^11) or narrowed to ^11 before you bake it into an upgrade plan.

Look elsewhere when:

• You are not on Laravel or not on Lighthouse. The value here is the integration, not the renderer; use upstream GraphQL Voyager directly.
• You need a supported, SLA-backed documentation surface. Five stars and a small release history mean you should expect to read the source and potentially fork. If schema docs are customer-facing or contractually referenced, a maintained schema registry or docs platform is the safer buy.
• You need more than visualization — schema diffing, changelog enforcement, usage analytics, or persisted-query tooling. Voyager shows you the graph; it does not govern it.
• Policy forbids exposing the full schema, even internally. An accurate graph is an accurate attack surface map; if your security posture treats schema as sensitive, this tool is off the table regardless of gating.
• Your framework version sits outside the tested window. Support was last extended in April 2024; verify current-major compatibility rather than assuming it, and weigh the maintainer's lag on framework releases as an ongoing cost.

How to Pitch It (Stakeholders)

Executives: "A small, MIT-licensed internal tool that renders our GraphQL schema as an interactive map, so engineers and support can answer API-shape questions without reading code or asking a senior engineer. No licensing cost, no infrastructure, no customer-facing surface — one route, gated by our existing auth. The risk is deliberately small: if it doesn't earn its place, we delete a dependency and a route in an afternoon. The honest caveat is that it is a small open-source project, so we are buying convenience, not vendor support — which is exactly why we're keeping the blast radius this narrow."

Engineering: "Add mll-lab/laravel-graphql-voyager as a Composer dependency; it auto-discovers, publishes config and assets, and points at our Lighthouse endpoint out of the box. Work is roughly half a day: install, publish, set the endpoint and route path, apply our auth middleware, and verify it renders against the real schema. Two things to check before we merge — whether the version constraint still allows our current Laravel major, and whether the route is properly gated in any environment reachable from outside the VPN. Pin the version, treat it as dev/staging-first, and plan to re-verify it at each framework upgrade, since a small project may lag majors. If the constraint turns out to be narrowing rather than additive, sequence this after the framework upgrade rather than blocking on it."