Laravel Bakery Laravel Package

Getting Started

Bakery is a schema generator, not a GraphQL server. It reads your Eloquent models and emits a .graphql SDL file that Lighthouse then serves. Treat those as a pair from the start.

composer require scrnhq/laravel-bakery nuwave/lighthouse
php artisan vendor:publish --provider="Bakery\BakeryServiceProvider"

The first file to open is config/bakery.php. It holds the output path for the generated SDL (typically graphql/bakery.graphql) and a models array — this list is the entire surface area of what Bakery will expose. Anything not in it does not exist in the schema.

Point Lighthouse at the generated file (config/lighthouse.php → schema.path), then register a single model to see the shape:

// config/bakery.php
'models' => [
    App\Models\Post::class,
],

Generate and inspect before wiring up a client:

php artisan bakery:build   # or re-run on boot in local; see the provider
php artisan lighthouse:print-schema

Your first real use case should be read-only: a Post type with posts and post(id:) queries, plus belongsTo relations (author, comments). Don't add mutations until you can query the type from GraphiQL and confirm relation resolution works the way you expect.

Implementation Patterns

Let relationships drive the schema, not hand-written types. Bakery walks belongsTo, hasMany, hasOne, belongsToMany, and morphMany. Define the relation on the model and it appears as a field. The win is that one models entry cascades into a whole subtree — but only if the related model is also in models. Otherwise the field is emitted as a scalar or dropped (behavior differs by version; verify the printed schema).

Use the model contract for per-model customization. Models opting into Bakery implement the supplied interface/trait to declare hidden fields, custom type names, or authorization hooks. This is where you exclude password, remember_token, internal flags, and pivot columns — default exposure is broad, so audit before shipping.

Mutations map to CRUD by convention. Bakery generates createPost, updatePost, deletePost-style mutations. Treat the generated mutation input as a scaffold: for anything nontrivial (publishing workflows, soft-delete semantics, computed fields) write a custom Lighthouse @field resolver and leave Bakery to own the types.

Split generation from serving. Commit the generated .graphql file and diff it in CI. A PR that unexpectedly changes fifty lines of schema is usually a model cast or relation change — catching it in review is far cheaper than catching it in a mobile client after deploy.

Compose with Lighthouse directives. Bakery emits plain types; layer @guard, @can, @paginate, @cache, and @complexity on top via a wrapper schema or a custom schema-stitching step. Don't fight the generator to add auth — put it after generation.

Gotchas and Tips

• The package is frozen at 2021. Expect friction on Laravel 10/11 and newer Lighthouse majors — primarily around PHP type declarations, service-provider signatures, and Lighthouse's schema-loading API. Pin both packages, and budget a fork if you're on a current stack.
• N+1 is the default failure mode. Generated relation fields resolve per-parent unless you apply Lighthouse's @hasMany/@belongsTo batch-loading directives or eager-load in resolvers. A three-level query can easily issue hundreds of statements. Profile with Telescope on the first real query, not after launch.
• Attribute casting leaks. $casts of date, datetime, decimal, json, and enums map unevenly to GraphQL scalars. Check every cast against the printed SDL — a json column becoming String (rather than a typed object) surprises people.
• Authorization is not automatic. Bakery generates the field; it does not scope by the authenticated user. A BakeryUser-style contract ties the schema to your guard, but you still must add @can/policy checks on mutations. Verify with two different users before trusting it.
• Config caching bites in production. If schema is generated at boot, a cached config that omits a model means that model silently disappears from your API. Keep a CI step that prints the schema and greps for expected types.
• Debugging is "print the SDL." When a field is missing, run the print command and read the file — the generator's errors surface there, not in a nice exception. If the schema is stale, clear the compiled output and regenerate.
• Extension point is the model, not the config. Reach for traits/contracts on the model for custom fields and naming; the config array is for registration and paths only. Overloading the config leads to unmaintainable one-off hacks.
• Know when to stop. Bakery shines for CRUD-shaped internal tools and prototypes. The moment you need unions, custom scalars, subscriptions, or federated subgraphs, hand-written SDL with Lighthouse's @field is clearer than bending a generator that hasn't shipped a release in three years.