[Proposal] Deprecate SelectFields in favor of Laravel AEL + Dataloaders

[illambo]

Proposal: Deprecation of the SelectFields Component

Note: This is a preliminary analysis prepared with the help of Claude Opus 4.6 (Anthropic) to expedite the evaluation process. I have revised the analysis and conclusions; I share the full reasoning for transparency. If there is a "code of conduct" regarding this, please let me know.

Context

SelectFields (~650 lines, ~110 test files) analyzes the GraphQL AST to build optimized ->select() and ->with() Eloquent calls. Over time it has become a black box — tightly coupled to Eloquent internals, hard to debug, and difficult to maintain or extend safely. Bug reports and edge cases (unions, interfaces, morphs, MongoDB, nested wrapping types) tend to surface in ways that are hard to reason about without deep knowledge of the component.

With Laravel's Automatic Eager Loading (Laravel 12/13), the framework now natively solves N+1 — which was the primary reason SelectFields exists. This library also already "ship" (encourages use) with Dataloaders, the standard GraphQL pattern for N+1 prevention, which work with any data source via webonyx/graphql-php's deferred resolution.

---

Comparison

Capability	SelectFields	Laravel AEL	Dataloaders
N+1 prevention	AST-driven upfront eager loading	Zero-config reactive batching	Deferred collect + batch
Column selection	SELECT col1, col2	SELECT *	SELECT * (customizable per loader)
Data source	Eloquent only	Eloquent only	Any (Eloquent, APIs, caches, etc.)
GraphQL context access	config['query'] closures receive args + ctx	None	Full — resolver has $args, $context
Relation scoping	Per-field closures on type config	constrainedEagerLoad / scopes (model level)	Logic inside the loader or resolver
Type configuration	model, alias, selectable, always, etc.	None	None
Maintenance cost	~650 lines of complex code	Zero (framework)	One simple class per entity

Bottom line: 95% of SelectFields' value was eager loading — now covered by both AEL and Dataloaders. The only truly unique feature is automatic column selection via AST analysis, achievable manually in a loader with ->select([...]). Dataloaders also cover context-aware relation scoping, which was considered a unique SelectFields selling point.

---

Options

	Effort	Maintenance	Decoupling	Future-proof
A — Extract as dependent package (requires rebing/graphql-laravel)	Low	Same	Low	No
B — Extract as standalone package (own contracts, no Rebing dependency)	High	Reduced	High	Yes
C — Remove entirely (rely on Laravel AEL + Dataloaders)	Medium	None	N/A	Yes

Option A moves the code but doesn't solve the black-box problem — circular dependency risk, can't evolve independently.

Option B enables a clean evolution path but has the highest effort (contracts, adapter, test migration).

Option C eliminates ~650 lines + ~110 tests, simplifies the resolver API, aligns with framework direction. Breaking change, but the migration path is well-defined.

---

Breaking Changes & Alternatives

Lost Feature	Alternative
SelectFields injection in resolvers	AEL handles eager loading transparently; or use a Dataloader
config['always'] / config['alias'] / config['selectable']	Model $appends, $hidden, accessors; or control in the loader/resolver
config['query'] (custom query with GraphQL context)	Dataloaders — resolver has full access to $args and $context (see example below). AEL scopes have no GraphQL context access
Column-level SELECT optimization	->select([...]) inside the loader (see example below). SELECT * is fine for most apps
Union/Interface/Morph traversal	Per-type loaders with explicit resolution

Migration paths (Option C)

• Minimal (AEL): Remove SelectFields usage, let Laravel handle eager loading. Suitable for most Eloquent-only apps.
• Full control (Dataloaders): Replace with loader classes. Recommended for context-aware scoping, non-Eloquent sources, or column-level precision. See the Dataloaders documentation.

A migration guide with before/after examples would be essential.

---

The Core Questions

1. Is column-level selection worth the complexity?

Is maintaining ~650 lines of complex code (union, interface, morph, MongoDB, wrapping types...) worth SELECT col1, col2 over SELECT *?

It matters mainly for tables with 50+ columns, blob/text fields, or high-throughput APIs. For most apps, SELECT * is fine.

Column selection in a Dataloader

// One line — no AST analysis needed
$users = User::whereIn('id', $ids)->select(['id', 'name', 'email'])->get()->keyBy('id');

2. Do you rely on context-aware relation queries?

config['query'] closures receive GraphQL arguments and context. Laravel AEL scopes have no GraphQL context access — but Dataloaders do:

Context-aware loading with Dataloaders

'posts' => [
    'type' => Type::listOf(GraphQL::type('Post')),
    'args' => [
        'status' => ['type' => Type::string()],
    ],
    'resolve' => function (User $user, array $args, $context) {
        return app(PostsByUserLoader::class)->load(
            $user->id,
            $args['status'] ?? null
        );
    },
],

This means context-aware relation queries do not favor keeping SelectFields.

3. Does the query execution model matter to you?

SelectFields is preventive (single upfront query), AEL is reactive (lazy trigger + batch), Dataloaders are deferred (collect keys, then bulk fetch). All three avoid N+1 effectively. The practical difference is negligible for most applications.

---

Recommendation

Option C (remove entirely) appears to be the strongest path forward. Laravel AEL + Dataloaders cover every SelectFields use case with clearer separation of concerns and lower maintenance burden.

---

Discussion

1. Do you actively rely on SelectFields? Which features specifically?
2. Is column-level selection important for your use case? Or was N+1 prevention the main reason?
3. Could column selection be solved differently? (e.g. ->select() inside a dataloader)
4. Which option do you prefer? A, B, or C?
5. Are you already using Dataloaders? If so, do you still use SelectFields alongside them?

We'd love to hear the community's opinion on this topic.
Thanks!

[mfn]

I don't think this considers the pagination and it's wrap-type marker interface.

Removal is ofc. easy, but what would be the sanction path forward. It's easy to say dataloader+AEL, but we would need specifics.

Also from https://laravel.com/docs/13.x/eloquent-relationships#automatic-eager-loading

This feature is currently in beta in order to gather community feedback. The behavior and functionality of this feature may change even on patch releases.

It would be irresponsible to bet on that IMHO.

[illambo]

Hi, I honestly missed the beta discussion...at this point I agree, let's put this aside for the future, even when we have more feedback from the community. Thanks for your efforts!

[mfn]

Of course this was a topic always on my mind since I was left being the only regular contributor and actually never truly using SelectFields (having never seen the value vs. the dataloader concept, etc.).

Anyway, I'm presenting "The Removal":

• Remove SelectFields #1257

I got in touch with the rebing/ owner and with their help I created the counter-part too:

• Spin off SelectFields into separate package graphql-laravel-select-fields#1

The goal now being that the final 10.0.0 release would already not include SelectFields anymore and would be accompanied with the 1.0.0 release of rebing/graphql-laravel-select-fields.

Quite some architectural things had to happen to make this possible, i.e. the invention of ResolverParameterInjector (still don't like the name), but that's the price to pay.

I tried to make it mostly drop-in compatible

So for the most basic use-case "it should just work ™️".

Otherwise, I tried to be detailed in the readme/upgrading guides.

I believe this is still not the final change for the 10.0.0 release. I think we need to give more guidance on how a non-SelectFields world looks like in practice.

[illambo]

💥Bigger and braver work! I'll check everything as soon as I can. Thanks 🙏