Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve N+1 queries tooling for GraphQL types #129

Open
Taucher2003 opened this issue Apr 16, 2024 · 0 comments
Open

Improve N+1 queries tooling for GraphQL types #129

Taucher2003 opened this issue Apr 16, 2024 · 0 comments
Labels
enhancement New feature or request tooling Related to project internal processes or tooling

Comments

@Taucher2003
Copy link
Member

Our current tooling against N+1 queries uses lookahead_field defined on the BaseObject.

def self.lookahead_field(field, base_scope:, lookaheads: [], conditional_lookaheads: {})
define_method(field) do |*_args, lookahead:, **_kwargs|
field_selected = lambda do |f|
lookahead.selects?(f) ||
lookahead.selection(:nodes).selects?(f) ||
lookahead.selection(:edges).selection(:node).selects?(f)
end
scope = lookaheads.reduce(base_scope.call(object)) { |acc, f| acc.preload(f) }
conditional_lookaheads.reduce(scope) do |acc, (f, preload_field)|
field_selected.call(f) ? acc.preload(preload_field) : acc
end
end
end

With this setup, the configuration for preloads has to be done on every type that includes the type affected by N+1 queries.

This should either be moved to resolvers or some custom tooling that defines the preloads on the affected type directly.

@Taucher2003 Taucher2003 added the enhancement New feature or request label Apr 16, 2024
@Taucher2003 Taucher2003 added the tooling Related to project internal processes or tooling label Oct 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request tooling Related to project internal processes or tooling
Projects
None yet
Development

No branches or pull requests

1 participant