running "afterware"

With combine we can add handlers to run before the main resolver. Useful for authentication checks and such.

I think it would be nice if we could also run some handlers after the main resolver. Think about credit transactions.

combineResolvers(reserveFunds, performAction, chargeFunds)

[smeijer]

@lucasconstantino, I’m aware of batching, but it’s not the holy grail either. It doesn’t combine requests from multiple child resolvers

query {
  blog(id: "x") {
    author {
      name
    }
    publisher {
      name
    }
  }
}

When authorId and publisherId are not equal, this will still hit the database three times. While we could optimize it, by fetching in the blog resolver:

  Query: {
    blog: async (_, { id }, { db }) => {
      const blog = await db.blogs.findOne({ _id: id });

      const users = await db.users.find(
        { _id: { $in: [blog.authorId, blog.publisherId] }}
      ).toArray();

      blog.author = users.find(x => x._id === blog.authorId);
      blog.publisher = users.find(x => x._id === blog.publisherId);

      return blog;
    }
  }

This is an oversimplified example of course, and in this specific case, I even might recommend against it. But taking the blog’s code from before:

query {
  blogs(first: 100) {
    author {
      name
    }
  }
}

If the first 100 blogs are made by 100 different authors. This would still result in 101 queries hitting the database. Even when using dataloader with it’s batching implementation. Unless I missed something huge in dataloader, it only protects you from requesting duplicate id’s. So when there are 25 different authors in this first 100 blogs, the database will only be hit 26 times. While we could reduce the count to 2 hits when we would iterate over the blogs our selves.

[lucasconstantino]

@smeijer I honestly forgot to answer you back then. Facebook’s data-loader not only facilitates caching, but batching. You should have a deeper look at that.