Lookahead and aliases

[czan]

I'm looking to do some aggressive pre-fetching of data for my GraphQL queries. As far as I can see, the right way to do this is to use "lookahead" values to tell me the shape of the query beyond the current field. This will let me know all the queries that I need to run up-front. I can then store that data and have the graphql-ruby library go through and marshal the data that I've pre-fetched, resolving any additional fields as needed (which may perform additional data fetches, depending on the fields).

This seems to be pretty straightforward in the regular case. That is, with a query like:

{ users { posts { title } } }

I can see how I would construct the SQL query and wire everything together to do this.

However, once aliases are involved, I can't see how to do it. That is, a query like this seems harder:

{ users { publishedPosts: posts(status: published) { id title }
          draftPosts: posts(status: draft) { id title } } }

I think my problem boils down to: alias information is not available on lookahead values.

In the documentation about lookahead there is a bit about aliases, but it seems to require you to know the aliases ahead of time. I can't see any way to get the alias of a given selection, and the code for alias_selection doesn't give me hope that this is easy. This doesn't make sense to me, because the client decides the aliases. I can't enumerate all possible aliases ahead of time, because any client can decide to use any name they like for a field, right?

Am I missing something? Apart from this issue with aliases, the lookahead mechanism seems perfect for what I'm trying to do.

[rmosolgo]

Hi! Thanks for the detailed question.

Yes, this is definitely what Lookahead is for, but I agree it's short on alias support.

The existing alias support is backward ... IIRC I built it when I was at GitHub and we had internal queries that needed special handling on the server, so we controlled both client and server in that case 😅

I did find a way to make it work, where you split the current lookahead based on the currently-executing alias: https://gist.github.com/rmosolgo/364a1023d9167376160a45ea847e1d89

I'm sure that's not exactly what you had in mind, but hopefully it gives a clue -- using lookahead.ast_nodes to identify aliases that are actually present, then deal with those selections independently.

Would an approach like that work for you?

[czan]

Just to check that I'm reading this correctly: selection.ast_nodes.map(&:alias).first gives the alias of a given selection, or nil if there is no alias? With this, I can iterate over selections and use the selection's alias, field, and arguments to work out whether/how to prefetch data.

If I'm understanding things, then that's perfect for my problem, thanks! With this I should be able to construct a query at the top-level which gathers all the values I need under their various aliases, then write field resolvers which pull them out.

It might also be worth adding a method to grab the alias directly off a Lookahead instance, but I'll leave that up to you to decide.

[rmosolgo]

To get the current field's alias, you'd need to do:

field :my_field, ..., extras: [:ast_node] # causes `ast_node:` to be added as a field argument 

def my_field(ast_node:)
  ast_node.alias # => returns the current field's alias, or `nil` if there isn't one. 
  # ... 
end 

If you use lookahead.ast_nodes.map(&:alias), it will return the aliases for all selections of the current field, without any guarantee of ordering. (I expect that ast_nodes would reflect the order in the query string, but I'm not sure that it's guaranteed.) For example, given a query like:

query {
  u1: currentUser { login }
  u2: currentUser { timeZone }
  currentUser { isAdmin }
}

The lookahead would give you:

def current_user(lookahead:)
  pp lookahead.ast_nodes.map(&:alias)
  # It would print once for each time that `currentUser` is resolved: 
  # => ["u1", "u2", nil] 
  # => ["u1", "u2", nil] 
  # => ["u1", "u2", nil]
  # ...
end 

Also, if you're really trying to plan SQL calls for the whole query, you can also get a "root level" lookahead as query.lookahead.