That does work indeed but say you were doing a second connection within the games connection.
If you were to do all connections this way, you’d end up querying the database multiple times, once
per successive connection, and running into the so called N+1 problem. That’s why dataloader comes
in handy, because it batches the associations and turns them into a single query automagically.

That’s why I was wondering if there was a solution really besides just doing separate queries…
If otherwise, I’d also be looking for a generic resolver that would work for all associations, so that
I wouldn’t have to care really about coding each of the resolvers manually.

A work-around that is working for me is to use dataloader for all queries, but if the GraphQL request is using pagination arguments on the specific resource, then add the parent_id to the dataloader args so that dataloader knows that it should not batch the SQL queries together. E.g. something like this:

import Absinthe.Resolution.Helpers, only: [dataloader: 2]

object :user do
  field :id, non_null(:id)
  field :name, non_null(:string)
  field :items, list_of(non_null(:item)) do
    arg :page, :integer
    arg :per_page, :integer
    arg :sort_field, :item_sort_field
    arg :sort_order, :item_order
    arg :filter, :item_filter
    resolve dataloader(Items, fn %{id: id}, args, _ ->
      {:items, case args do
        %{page: page, per_page: per_page} when is_integer(page) and is_integer(per_page) ->
          Map.put(args, :user_id, id)
        _ -> args
      end}
    end)
  end
end

This solution still results in the N+1 problem for this specific resource while using pagination on this resource, but you can still leverage batching for other resources in the query that are not being paginated.