Weave Code
Dataloader Bundle Laravel Package
overblog/dataloader-bundle
Symfony bundle integrating DataLoader PHP for efficient batched data fetching. Register loaders as services, reduce N+1 queries, and add per-request caching to GraphQL or REST resolvers with simple tags and autowiring.
This bundle allows to easy use DataLoaderPHP in your Symfony project through configuration.
Frequently asked questions about Dataloader Bundle
- Can I use overblog/dataloader-bundle in a Laravel application?
- Not idiomatically. This package is a Symfony bundle that relies on a Symfony kernel, bundle registration, compiler passes, and tagged service definitions, and Laravel's container does not consume Symfony bundles. Pulling symfony/framework-bundle into a Laravel app just to satisfy bundle registration is operationally heavy and non-standard, and composer why-not will typically show the bundle as unsatisfiable without it. The realistic path for Laravel is to use webonyx/graphql-php's framework-agnostic DataLoader primitive directly and own the wiring yourself.
- Does overblog/dataloader-bundle support Laravel 10 or Laravel 11?
- No. There is no Laravel service provider, no package auto-discovery, and no Laravel test matrix in this project; its compatibility surface follows the Symfony release cycle. The 1.1.0 release simply widened constraints to Symfony 7.1 and added nothing Laravel-facing. Treat any expectation of Laravel version support as out of scope and look at webonyx/graphql-php or a Laravel-native GraphQL package instead.
- What does overblog/dataloader-bundle actually do?
- It is the Symfony glue around DataLoaderPHP from webonyx/graphql-php. It lets you register loaders as services through configuration, tag and autowire them, and get per-request caching so that GraphQL or REST resolvers batch fetches instead of issuing N+1 queries. The valuable batching and caching primitive itself lives in webonyx/graphql-php and is framework-agnostic; the bundle only handles container integration.
- How do I install and configure overblog/dataloader-bundle in a Symfony project?
- Install it with composer require overblog/dataloader-bundle and enable the bundle in config/bundles.php, then declare your loaders in the bundle configuration and tag or autowire the corresponding services. Because it is configuration-driven, most projects need little or no PHP bootstrap code beyond defining loader classes. This flow assumes a Symfony kernel, so it does not translate to Laravel.
- How are loaders registered as services with this bundle?
- Loaders are declared as normal Symfony services and picked up through the bundle's configuration plus service tags and autowiring. The bundle reads that configuration and exposes loader instances to your resolvers, with caching scoped to the request. In Laravel you would replicate this manually by binding a loader registry as a scoped singleton in a service provider so the cache resets between requests.
- How do I fix N+1 queries in a Laravel GraphQL API without this bundle?
- Use webonyx/graphql-php directly and prototype a request-scoped DataLoader registry inside a service provider, binding it as a scoped instance so batching and caching live for exactly one request. That typically takes roughly 50 to 150 lines of Laravel-specific wiring, which is the trade-off versus depending on a Symfony bundle. Measure query-count reduction on your worst resolvers and add tests that assert the expected number of queries before rolling it out broadly.
- What PHP and Symfony versions does overblog/dataloader-bundle 1.1.0 require?
- Version 1.1.0 widens support to Symfony 7.1, which requires PHP 8.2 or newer, so widening the constraint will not help if your runtime is still on PHP 8.1. Check the resolved constraint set with composer why-not before merging, especially in a monorepo with pinned Symfony components. For a Laravel-only app the floor is usually moot because the bundle cannot be satisfied without framework-bundle anyway.
- Is upgrading to overblog/dataloader-bundle 1.1.0 a breaking change?
- No. Release 1.1.0 is a narrow compatibility widening that adds Symfony 7.1 support, with no new features, no public API changes, and no deprecations. For a Symfony 6.4 or 7.0 application already using the bundle it is a drop-in composer update. The only real caution is verifying it does not conflict with other pinned Symfony packages in your dependency graph.
- What are the Laravel-native alternatives to overblog/dataloader-bundle?
- For GraphQL, look at Lighthouse's built-in batching directives, laravel-data, or a custom deferred and promise batching layer built on webonyx/graphql-php. For plain Eloquent N+1 problems the answer is usually eager loading with with() and preloading relationships rather than a DataLoader. Pick based on whether you actually run a webonyx-based GraphQL layer, since batching primitives only pay off in that architecture.
- Does DataLoader batching solve Eloquent N+1 problems on REST endpoints?
- Generally no. DataLoader is a promise and deferred batching primitive designed for graph-style resolvers that request many small keys per field, and it does little for typical REST controllers or Eloquent relationship loops. Profile first to confirm N+1 is the actual bottleneck, then use eager loading, chunking, or query-count assertions in tests. Adopting a batching primitive before you have profiling data usually adds complexity without measurable gain.
Weaver
How can I help you explore Laravel packages today?