Reducing executor

[freiksenet]

Hello!

In our system we took GraphQL query and translated it to ReQL (RethinkDB query language) for execution. This allowed us to optimize the query, eg use built-in joins in ReQL instead of querying the database two times. I can see how the similar system can be used for, eg, SQL queries. We also did some further optimizations, like returning only the fields that are requested by GraphQL, reducing the response payload size for tables with many keys.

I see a way to do it graphql-js by manually going through selection sets in resolve, but that feels very clumsy and hacky, as the library does this walking already. Some ways to do it would be to allow children resolve to modify root or to split collect/resolve/complete steps into independent parts that can be used separately.

Do you think deferred execution and query translation is a good idea? Should we stick to current model and do multiple requests to the database? Is there some solution to that, which I don't see?

Thanks!

[freiksenet]

Mapping vs reducing executor

Discussed this with @dschafer in IRC a bit, he asked to provide some concrete
examples of what we would like to be able to do with executor.

As I understood, the current executor was made with the assumption that it's
okay to make multiple round trips, so it's built from top down. If resolve is
defined on some lower level fields, they get access to parent result and can
query backend once more. One can say current executor uses map over tree,
calling appropriate resolve function on each node.

In our system, we assumed that extra round-trips are bad and that, as our
system allows it, we would like to be able to express GraphQL queries with one
query, when it is possible. We also figured we can do optimizations along the
way, like requesting only the selection set fields in the query. Our executor
collected results of what is similar to resolve in graphql-js and then
combined them together. One can say we did reduce over the tree, calling the
resolve function along the way and then combining the result.

Let's imagine schema:

type User {
  id: String!
  name: String
  posts: [Post]
}

type Post {
  id: String!
  text: String
  createdAt: DateTime
  author: User
}

Mapping executor

We assume we have fields in query to get User and Post by id. Resolve for
one of them would look something like:

resolve(parent, {id}, {db, conn}) {
  return db.table('User').get(id).run(conn); // Promise
}

For relations (like author or posts) we'll have something like

resolve(parent, args, {db, conn}) {
  return db.table('Posts').get(parent.author).run(conn); 
}

Reducing executor, version 1

This is approximately how we do it.

Here we would need some abstraction, which can later be converted to database
query. We call it Query (duh), the main idea is that it's easily convertible
to actual database request.

resolve(parent, {id}, {db, conn}) {
  let baseQuery = new Query({
    selector: new IDSelector({id: id, tableName: tableName}),
  });
  // this calls resolve on each child and returns results (queries)
  let childrenResults = this.resolveChildren(baseQuery); 
  let finalQuery = combineQueries(baseQuery, childrenResults); // combines query together
  // We actually just return the query and run and later stages
  return finalQuery.run(db, conn);
}

Relation resolves would be like this:

resolve(baseQuery) {
  let newQuery = new Query({
    selector: new RelatedSelector({
      tableName: tableName, 
      relatedField: fieldName
    }),
  });

  let childrenResults = this.resolveChildren(newQuery);
  let finalQuery = combineQueries(newQuery, childrenResults);
  return baseQuery.addJoin(fieldName, newQuery)
}

One can also apply some optimizations by having custom resolves for scalars.

resolve(baseQuery) {
  return baseQuery.addToSelect(fieldName)
}

Reducing executor, version 2

What I propose is to add reduce method to the fields, in addition to resolve. The default
implementation of reduce would do what it does now - take the result of resolve
of children and put it to appropriate places in the object. Simplified example:

reduce(ownResult, childrenResultMap) {
  for (let key of childrenResultMap.keys()) {
    ownResult[key] = childrenResultMap[key];
  }
  return ownResult;
}

This would convert what we had in version 1 to:

// query field
resolve(parent, {id}) {
  return new Query({
    selector: new IDSelector({id: id, tableName: tableName}),
  });
  return baseQuery;
}

reduce(parent, ownResult, childrenResultMap, {conn}) {
  return combineQueries(ownResult, childrenResultMap).run(conn)
}

// join
resolve(parent, {id}) {
  return new Query({
    selector: new RelatedSelector({
      tableName: tableName, 
      relatedField: fieldName
    }),
  });
}

reduce(parent, ownResult, childrenResultMap) {
  return parent.addJoin(
    combineQueries(ownResult, childrenResultMap)
  );
}

[ecstasy2]

The idea of a reducing executor is appealing, but I think any reducing executor will have to make assumption on the domain specific structure of the application.

An alternative I am using is queries collapsing. It kind of achieve the same goal but without making the spec too opinionated.
Basically a resolver send to a custom query merger module and listen to an event on the merger before resolving the promise.

The query merger is configured to reduce round trips to the db and would wait a specified amount of time to receive more queries to merge and send to the database.

[ecstasy2]

For example all mapping executor you provided assume that a relationship is actually in a different location and thus require a query to be resolved. While if I am using a document based datastore I might not need that query.

[freiksenet]

I don't think it makes any assumptions, I was just showing how it solves the problem in my domain. In your alternative solution, reducer could collect individual queries in reduce step and execute them all together at the end. Similarly, executor doesn't dictate where you add reduce and resolve, so if you keep your data inline, you just won't need to add them.

[pushrax]

I agree with this approach, and it seems general enough to be included in the spec. It's still useful with document stores for limiting the requested fields.

Using a debounced merger seems like a very specific solution for multithreaded or evented architectures, and has implications on latency. In addition, the query flow becomes much more difficult to reason about.

I'm interested in how FB approaches this; you probably have something figured out already.

[devknoll]

There's a little bit of discussion about this going on in #19 too, might help to merge the discussion somewhere.

[ecstasy2]

@pushrax The debounced merger I suggested is definitely not a solution that I am suggesting for the spec. I just noted how I am solving this particular issue in the context of my implementation.

The problem I see with the reducing solution above is that it assume that we could always find a way to reduce field selection into smaller queries. I am just saying that the reduce part will always be domain specific and might not be a good fit to be in the spec.

My vote would be to the resolver functions enough meta data on the context of the selection so that kind of implementation is possible.

[leebyron]

The problem I see with the reducing solution above is that it assume that we could always find a way to reduce field selection into smaller queries. I am just saying that the reduce part will always be domain specific and might not be a good fit to be in the spec.

I fear a similar outcome, but I'm interested in what could become a more general utility to provide.

Right now we offer the field AST as one of the arguments to the resolve function, but I agree this is not enough to implement an effective reducer. It doesn't make fragment resolution or sub-field merging easy to manage.

Any reducer needs to support this case:

{
  me {
    ...friendNames
    ...friendBirthdays
  }
}

fragment friendNames on User {
  friends {
    name
  }
}

fragment friendBirthdays on User {
  friends {
    birthday
  }
}

Once reduced, the query executor is still going to want to use a top-down descent into the result so that it can ensure the returned result adheres to the type system contract: that non-nullables are in fact not null, that scalars are of the correct types, and that no additional fields have leaked through.

[dschafer]

Chatted with @leebyron just now.

It seems pretty clear that we're missing something here to make this case easier. There seem to be a couple of approaches that might work:

• The core executor could implement a reducer as you suggest.
• The core could add a collect step as you suggest, that traverses the tree from bottom to top, so that every resolve method gets the result of resolving its parent as well as the result of collecting its children as inputs.
• One could write a library that allows the type definitions to be specified in whatever manner is easiest for you, and that produces type definitions that use the existing API.
• Others that we haven't even thought of yet.

My instincts personally run towards the collect step, but I think the way we'll get to the ideal solution here is by experimentation and trying things out.

So I'd suggest you take whichever option makes the most sense to you and build it as an temporary extension to the core right now; for example, if you wanted to build out the "collect" pass, it could be implemented as a temporary step prior to execution that uses the TypeInfo and visitor abstractions in the core to construct a "collected data" object, which would be passed into the execute function as the root object. So you wouldn't use the built-in graphql function, but instead build one that does your extension; for example, it might parse, validate, collect, then execute.

By building out a solution as a temporary extension to the core, we'll be able to figure out which of the options ends up being easiest and cleanest, and we'll see if different implementations end up requiring similar techniques. Once we know that, we'll hopefully discover the general piece that we're missing, and figure out the right way to add it.

Super excited to see how this development proceeds, I think seeing what the temporary extension looks like will make it really clear what the right changes to make to the core are!

[freiksenet]

@dschafer I don't quite understand what's your idea about collect. What exactly would "collecting children" imply?

@leebyron I don't see a problem with reducer and the fragments, fragments seem to be resolved to flat field map on collectFields stage, so for the reducer there would be no difference between having fragments or just getting both fields 'directly'.

And yes, reduce would be domain specific, exactly like resolve is domain specific. It's just tools you can use to customize the way the executor work. I've given an example of generic/default reduce, which does exactly what executeFields does after executing the field.

I'll try to hack implementation to illustrate what I mean, I think it'd be easier :)

[freiksenet]

Ah, I think I get what @dschafer means. That would work too.

[freiksenet]

Riiight, I was wrong about collectFields and fragments. Now I get what @leebyron was talking about. Back to the drawing board.