Weave Code
Laravel Graphql Utils Laravel Package
laragraph/laravel-graphql-utils
A collection of practical GraphQL utilities for Laravel applications, offering reusable helpers for schemas, types, directives, pagination, and testing so you can build robust APIs with less boilerplate.
Utilities for using GraphQL with Laravel
Frequently asked questions about Laravel Graphql Utils
- What is laragraph/laravel-graphql-utils used for?
- It is a thin utility layer that sits between Laravel's HTTP layer and webonyx/graphql-php, offering reusable helpers for schemas, types, directives, pagination and testing. It does not own routing, persistence or domain logic, so it can be adopted or removed without reshaping your application architecture. Many Laravel GraphQL stacks already run it implicitly as a transitive dependency of Lighthouse.
- How do I install laragraph/laravel-graphql-utils with Composer?
- Run composer require laragraph/laravel-graphql-utils and commit the updated composer.json and lock file. Typical usage needs no service provider configuration, environment variables or database migrations. If the package already arrives transitively through Lighthouse, check with composer why before pinning it explicitly in your root composer.json.
- Which Laravel and PHP versions does it support?
- It is compatible with Laravel 9, 10 and 11 on PHP 8.x, and with any stack running webonyx/graphql-php, including Lighthouse-based APIs. Nothing in the utility layer is tied to a specific Laravel minor version, so patch releases are generally safe to apply. Confirm that the webonyx constraint resolves cleanly against the version already pinned in your stack.
- Does this package replace Lighthouse or webonyx/graphql-php?
- No. It is a low-coupling utility package rather than a full GraphQL server framework, and it complements webonyx/graphql-php instead of replacing it. Lighthouse and similar packages build schema definition and execution on top of webonyx, and often pull these utilities in as a dependency. Use it when you want shared helpers without committing to a particular server implementation.
- How do the pagination helpers work?
- The package provides reusable helpers for cursor and offset paginated GraphQL responses, so you do not have to hand-roll connection types, edges and page info for every list field. They work alongside your existing schema definitions and do not change how requests are routed or resolved. Check the README for the exact helper signatures before adopting them in a new schema.
- Can I use this package to test GraphQL APIs?
- Yes, it includes testing utilities aimed at asserting on GraphQL responses and schema behaviour inside Laravel's test suite. When upgrading, add targeted negative tests for malformed batch payloads and assert a 4xx status with a well-formed error body. Also verify that your global exception handler renders the rejection rather than masking it as a 500.
- Will upgrading to 2.3.2 break my GraphQL clients?
- Version 2.3.2 is a semver patch with no public API, configuration or migration surface, so integration is just a Composer update or lockfile bump. The only behavioural change is that batch payloads containing non-object entries are now rejected up front instead of raising a TypeError. Clients sending non-standard batch shapes will receive explicit rejections rather than unhandled 500s, which is correct behaviour but a visible contract change for those callers.
- Is it safe to run in production given the small maintainer pool?
- The parsing layer is internet-facing in most deployments, so keeping it current matters: 2.3.2 removes an unhandled 500 and a minor information-disclosure vector for malformed input. The maintainer pool appears small, so track upstream releases and review changelogs rather than letting the dependency drift. Because the package is thin, it can be removed later without reshaping your application architecture.
- How do I tell whether this package is a direct or transitive dependency?
- Run composer why laragraph/utils to see whether the package is required directly or pulled in through Lighthouse. If it is transitive, coordinate the Lighthouse bump rather than pinning the utility yourself, and confirm no other package constrains it below 2.3.2.
- How should I roll out the update and monitor it?
- Deploy to staging first and run your GraphQL integration tests plus targeted negative tests covering numeric string keys, mixed object and non-object batch entries, and multipart equivalents. Canary to production and watch 4xx and 5xx rates on the GraphQL endpoint for 24 to 48 hours. A 4xx increase reflects expected client non-conformance, while a 5xx decrease validates that the fix is working.
Weaver
How can I help you explore Laravel packages today?