Query evaluation to limit preloading associations

[natecox]

Forgive me if this is a rookie question, but I couldn't find any information that directly addresses my issue.

Is it possible within Absinthe to evaluate the fields provided in a query, so that associations can be pre-loaded intelligently in the resolvers? As it currently stands, the project I'm working on is getting to a point where we are having to break a nested query into separate queries because the preload requirements were cumbersome.

As an example, assume we have the models Book, Chapter, and Section; where a book contains chapters and chapters contain sections.

If I write a query such as:

{
  book {
    author
    title
    chapter {
      title
    }
  }
}

I don't want to preload the associations for sections because they're not actually going to be used. However, because I can't inspect the query, I'm not certain in the chapter resolver if I need those associations or not so I need to err on the side of caution.

While the example above is trivial, the practical data model that we're working with requires relatively deep nesting, and the association preloading was generating overhead that has required us to change our strategy and break nested components into separate endpoints. This results in more calls to the server, and begins to negate one of the biggest selling points to GraphQL in my opinion: fewer, simpler "endpoints"

So, long story short: is there a mechanism in place to allow me to evaluate a query before the resolver has been called, and tailor the association preloading to the query being made?

[benwilson512]

Hey there, this is a great question. The first thing you'll want to do is look at the https://hexdocs.pm/absinthe_ecto/Absinthe.Ecto.html project, which provides some helpers for dynamically loading ecto associations.

It takes a slightly different approach than the one you're suggesting. Instead of looking down the query in order to preload at the top, fields that require associations are batched together lazily. This can actually produce even fewer queries than preloading at the top.

Your approach is still an interesting one though, and it's one others have brought up before: absinthe-graphql/absinthe_ecto#4. There are a lot more tools now to handle this than there were, most importantly the https://hexdocs.pm/absinthe/Absinthe.Resolution.html#project/2 function.

At this point there's nothing stopping end users like yourself from playing with this further. As a core team we're pretty happy with where absinthe_ecto is at for the moment, in the sense that it isn't likely to be the main focus for a bit. Stuff like subscriptions and the schema internals re-work are higher priority for us.

That said, we'd love to see others take a stab at combining project/2 with schema annotations and the like to try out other ways of doing relational database loading.

[natecox]

@benwilson512 we're still playing around with the best way to handle this internally, thanks for the information. If we come up with anything interesting we'll post it back here, but feel free to keep this closed.

[benwilson512]

Awesome, I'd love to hear about whatever you come up with!

[sergiotapia]

@benwilson512 running into this same issue today - do you know if anything has been updated for these situations?

[benwilson512]

Hi @sergiotapia things have changed quite a lot since 2017, I'd checkout https://hexdocs.pm/absinthe/1.5.0-beta.2/Absinthe.Resolution.html#project/1 and https://hexdocs.pm/absinthe/1.5.0-beta.2/ecto.html#content

[sergiotapia]

Thanks @benwilson512 - for any would be searchers that find themselves here. I ended up using dataloader to prevent these n+1 issues.