Prepared queries without known variables

[msolomon]

I'd like to be able to prepare (and ideally, run query reducers over) queries that incorporate variables before I actually have values for the variables.

For example, I'd like to prepare a query that requires a $userId variable, then subsequently execute that prepared query for any user ID passed in the variables.

The main use case is to support efficient execution[1] of persisted queries. Sangria's existing Prepared Query support is great, but requires that variables are known at preparation time.

Combined with #195, Sangria's support for prepared/persisted queries would be great.

What do you think? The include/skip (and custom?) directives would need to be applied after variables are known, but I think that's the main hiccup.

---

[1] I'm generating implementations to fulfill GraphQL queries dynamically, so it would be much more efficient if we did this once per query (without variables filled in) instead of on every request.

[OlegIlyenko]

Thanks for opening the issue and continuing the discussion on this topic. In fact, I already did a few experiments in this area after #195. It is a bit non-trivial to add this feature, but not impossible :)

One of the unclear points (and I would say the most important one) is how to handle the variables that might influence complexity. For example:

query Foo($lim: Int!) {
  users(limit: $lim) {
    id
    name
  }
}

In absence of variables, $lim is unknown. users returns the list of users, so somehow we need to provide information about the worst-case scenario which is the max size of the user list that can possibly be returned. What do you think is the best approach to deal with this situation?

If we consider the subset of query reducers that are currently available out-of-the-box, then measureComplexity/rejectComplexQueries are the only one that influenced by this.

[msolomon]

Yes, that makes sense--I'm not surprised you already had this idea!

Variables show up in two places: arguments to fields, and arguments to directives. I think the least API-breaking change is probably extending sangria.schema.Args to include the notion of args without known values.

If that was the main change and QueryReducers could be run at preparation as well as at execution time, then authors of QueryReducers would need to branch depending on if variables they care about are missing (during query preparation) or available (during query execution). It seems fairly natural to extend Executor.prepare to take a list of query reducers as an argument for running at preparation time instead of execution time.

Another option is to introduce another type of reducer that runs at preparation time instead of execution time and doesn't have access to variable values (only their types). This might be less compelling.

[msolomon]

Updated #281

[OlegIlyenko]

Fixed in #281