Graphql Laravel Package

Product Decisions This Supports

• Build vs. buy for the API layer. This package is a thin abstraction over webonyx/graphql-php, the de facto GraphQL engine for PHP. Adopting it is effectively a decision to own a wrapper rather than adopt a maintained, opinionated framework (e.g. Lighthouse). That trade-off belongs on the roadmap explicitly.
• GraphQL adoption / BFF strategy. Supports product moves toward a Backend-for-Frontend or partner-facing GraphQL endpoint — reducing over-fetching for mobile clients, aggregating multiple REST services behind one schema, and decoupling client release cycles from backend changes.
• Schema ownership and governance. An abstraction layer implies a schema-first or code-first convention that the team must standardize on. This shapes how product requirements (new fields, deprecations, versioning) get translated into API contracts.
• Vendor and maintenance budgeting. With zero stars and zero dependents in a private repo, the real product decision is who owns this code and what happens when the original author leaves. That is a resourcing decision, not a technical one.

When to Consider This Package

Consider it when:

• You are already standardized on webonyx/graphql-php and want Laravel-idiomatic glue (service provider, config, type registry) without a heavy framework.
• You are inside the owning organization (BNN-VARA) or otherwise have durable access to the private repository and the ability to fork and patch it.
• Your schema is small and stable, your team is comfortable reading the underlying library, and you value a minimal, inspectable abstraction over batteries-included tooling.

Look elsewhere when:

• You cannot access the repository, or cannot guarantee long-term maintenance — a private package with no public history is unauditable and unpatchable for outsiders.
• You need SDL-first development, directives, Eloquent-integrated resolvers, subscriptions, or file uploads out of the box; Lighthouse covers these with an active community.
• You require security advisories and upstream fixes on a predictable cadence.
• You are evaluating it on ecosystem signal alone — zero stars and zero dependents means no third-party vetting, no issue history, and no evidence of production use beyond the author.

How to Pitch It (Stakeholders)

To executives: This is a small internal abstraction over a proven open-source GraphQL engine, not a new platform bet. It lowers the cost of exposing a GraphQL API and standardizing how our services talk to clients. The risk is ownership, not technology: it is a private package with no public adoption, so we must budget engineering time to maintain it ourselves. Recommend a time-boxed spike and a named owner before committing.

To engineering: Expect a thin, readable wrapper around webonyx/graphql-php — likely Laravel service-provider wiring and type/schema helpers. Audit the source before adoption: check Laravel and PHP version constraints, test coverage, and how it handles authorization and error masking. If the wrapper is trivial, consider depending on webonyx/graphql-php directly and keeping the glue in-house; if you want SDL-first ergonomics and an active maintainer, benchmark against Lighthouse before deciding.