rebing/graphql-laravel: a code first GraphQL layer for Laravel

Code first schemas written as PHP classes

rebing/graphql-laravel presents itself as a Laravel wrapper for Facebook's GraphQL, but the engine underneath is webonyx/graphql-php, the PHP port of the reference implementation. Facebook's own server code is not part of this package, so behaviour questions get answered by the port rather than by Meta. It is PHP only and drops into an ordinary Laravel request lifecycle, where queries and mutations become HTTP endpoints.

The defining choice is where the schema lives. Types, queries and mutations are PHP classes rather than `.graphql` schema files, so there is no schema text parsed at boot and no stitching step between a file and a runtime type map. A schema change becomes a pull request that static analysis can read. The cost is that every field needs a class or a closure behind it, and the documentation spends a Concepts subsection, A word on declaring a field nonNull, on the first mistake people make while writing one.

Install steps and quick start survive only as headings

The package is published on Packagist as `rebing/graphql-laravel`, and every badge at the top of the README points at that package page. What follows in the README text is a table of contents rather than prose: Requirements, Installation, then a Quick Start in four steps, Create a Type, Create a Query, Register in config, and Test it. No composer command, no service provider line and no environment variable appear under those headings in what the README reproduces, so the install command has to be taken from the Requirements and Installation sections on the repository page itself.

The root lists `composer.json`, `config/`, `tests/`, `bin/`, `tools/` and `tmp/` alongside `phpunit.xml.dist`, `phpstan.neon.dist`, `phpstan-stubs/`, `rector.php`, `.php-cs-fixer.dist.php`, `AGENTS.md` and `.roave-backward-compatibility-check.xml`. Two of those files touch adopters directly: a backward compatibility check is configured at the root, and `UPGRADE.md` holds the notes for anyone crossing a major boundary. Version 10.0.0 shipped on 2026-06-18, after 10.0.0-RC5 on 2026-05-27 and 10.0.0-RC4 on 2026-05-24.

Middleware comes in three separate layers

Three middleware concepts are documented, and mixing them up is the first thing to sort out. HTTP middleware runs inside Laravel's pipeline and can be scoped per schema. GraphQL execution middleware wraps a single GraphQL request and can be scoped per schema as well. Resolver middleware attaches to an individual query or mutation, runs around the resolve method, and has its own definition and registration steps plus a termable variant for work that must finish after the response has gone out.

Scoping by schema rather than by route is the part worth planning around. One application can serve an internal schema behind tight HTTP middleware and a public schema under a different set, with different execution middleware on each, without duplicating the route file. Queries return types, and those types carry their own privacy settings, so field visibility is decided where the field is declared. Authorization sits in a section of its own, next to Privacy, which leaves access control documented in two places instead of one policy file.

Two strategies against the n plus one problem

Two batching routes are offered against n plus one queries, and only one of them ships in this repository. Dataloaders use the deferred resolution built into webonyx/graphql-php to batch field loads from any data source, not only Eloquent, and the pages also cover plugging in an existing DataLoader library. SelectFields is the other route: it reads the incoming GraphQL query and writes the Eloquent calls itself.

What it writes looks like this.

select()
with()

Ownership is the catch. SelectFields lives in rebing/graphql-laravel-select-fields, a separate optional package linked rather than required, so choosing it means tracking two repositories instead of one. A Choosing an approach subsection covers that decision, and neighbouring sections handle eager loading relationships, type relationship queries and pagination for the cases where you want the relation written out by hand instead.

Validation attaches to arguments and nested inputs

Validation arrives in three documented shapes: rules declared per argument, a `rules()` method, and direct use of Laravel's own validator. Customizing error messages and attribute names is supported, and one subsection covers cross field rules inside nested input types, the case where a constraint spans two sibling fields instead of one value. Unknown variables are detected too, a small guard that matters more than it sounds on a public endpoint.

Because the type system is code, the awkward corners of the specification get their own sections: Input Object, OneOf Input Objects with a generator, Enums, Unions, Interfaces with shared interface fields, Scalar types, field deprecation and type modifiers. A default field resolver and macros cover fields that do not deserve an explicit resolve method. Batched requests are supported as well, which is what the batching limits entry under Security is counting.

Security knobs named without their default values

The Security section is a list of six topics: introspection, query depth limiting, query complexity analysis, batching limits, GET requests and read-only enforcement, followed by a recommended production configuration. What the README text gives at this point is that list of headings. Which limits start enabled is not stated there, and while `config/` sits in the root, its contents are not reproduced either. For a package whose job is exposing a query endpoint to callers, those defaults are the first thing to read before going live.

Error handling splits the same way: built in error types, a documented error response format, error reporting, and a hook for customizing the formatting. Read together, most of what separates a safe public endpoint from a careless one is configuration the adopter turns on personally rather than a default the package enforces for you.

Tracing and persisted queries for production traffic

Observability has four subsections of its own: enabling OpenTelemetry, per field resolver tracing, custom tracing drivers and per schema tracing. Per field tracing is the piece that pays off in a code first schema, because the resolver is a named PHP method and a span can carry that name into the trace. Without it, a slow GraphQL response reads as a slow Laravel request with parsing in front of it.

Automatic persisted queries are supported as well, with notes and a client example, so repeat calls can send a hash instead of the full query text. Field alias, input alias, JSON columns, macros and unused variable detection fill the same pragmatic tier. The default branch is master, and the Tests badge links to a workflow run, so the suite is wired into automation rather than left as a local script.

Lighthouse fills the gap left by subscriptions

The README states one gap explicitly, in a note near the top: GraphQL subscriptions are not supported by this package. For real time push it points at Lighthouse, which has subscription support, and otherwise at implementing subscriptions separately through Laravel broadcasting or WebSockets. That is the full extent of the comparison drawn here. Whether Lighthouse keeps its schema in files or in classes is not settled by this documentation, so choosing on subscription support alone means reading the other project yourself first.

The practical split is simpler than that comparison. Read heavy APIs with awkward relation loading fit this package, because deferred resolution, privacy settings and per schema middleware are the parts that are clearly built out. Presence, live chat and any feed that pushes without a request do not fit, and covering them means a second GraphQL stack beside the first. The deciding question is whether your clients subscribe, not which schema syntax your team prefers.

Editorial conclusion

rebing/graphql-laravel is a well considered code first layer for teams that already run Laravel middleware, validation and Eloquent and want a GraphQL API without a text schema file. It does not fit products whose clients subscribe to live data. Before adopting, read the Requirements and Installation sections, then open `config/` for the introspection, query depth and complexity defaults, since the visible README text covers both only as headings. The last push was on 2026-09-08, the repository is not archived, and the licence is MIT.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. rebing/graphql-laravel on GitHub
5. Releases