Feature: Data loader integration

[MichalLytek]

https://github.com/facebook/dataloader

1. Caching resolving the same data
2. Instead of normal resolving:

@FieldResolver()
author(@Root() recipe: Recipe) {
  return this.userRepository.findById(recipe.authorId);
}

Introduce batched resolving - taking array of roots:

@FieldResolver()
async author(@Root() recipes: Recipe[]) {
  const ids = recipes.map(r => r.authorId);
  return this.userRepository.findByIds(ids);
}

3. Decorator:

@Mutation()
async mutationThatAffectLoader(
  @Arg("input") input: SomeInput,
  @DataLoader(User) loader,
) {
  const result = await this.mutateSomething(input);
  loader.clear(input.someKey);
  return result;
}

[laukaichung]

Looking forwards to it on solving n+1 requests.

[laukaichung]

I'm not sure how it's supposed to work.

Does @FieldResolver() automatically cache the returned result with dataloader?

@FieldResolver()
author(@Root() recipe: Recipe) {
  return this.userRepository.findById(recipe.authorId);
}

It looks like I don't need to do anything at all that involves dataloader.
If it's true, I'll wait for the integration instead of starting to use dataloader now.

[MichalLytek]

@Resolver(() => Post)
class PostResolver {
  @Query(returns => [Post])
  posts() {
    return this.manager.find(Post);
  }

  @FieldResolver()
  comments(@Root() posts: Post[]) {
    const postIds = posts.map(post => post.id);
    const comments = this.manager.find(Comment, { postId: In(postIds) });
    // grouping and providing correct order for dataloader
    return posts.map(post =>
      comments.filter(comment => comment.postId === post.id)
    );
  }
}

So executing this query:

query {
  posts {
    id
    title
    comments {
      text
    }
  }
}

will call DB two times - one for fetching posts collection, one for fetching comments collection, because comments resolver will be batched.
And yes, field resolvers will be cached, so calling the field resolver with the same parent and args data will not execute it again.

[laukaichung]

This is great. It looks like the dataloader is working under the hood in @FieldResolver. I don't even need to call up @DataLoader(Comment) and explicitly cache the fetched comments in @FieldResolver.

[chrisdevereux]

When I've used DataLoader before, I've generally used it at the repository layer, rather than on resolvers. The main benefit of this being that it doesn't leak logic around batching into the service layer (requiring everything in the app to work on n ids rather than 1).

The main downside is that it requires me to construct services & repositories per-request. Which I can't really figure out how to do with TypeGraphQL — would require the resolvers & DI context to be constructed per request.

What do you think about solving this problem by allowing this, rather than bundling dataloader support into the resolver?

[MichalLytek]

It's easy to solve - create a global middleware that will create new dataloaders and attach them to context. Then you can use the loaders from context in resolver class methods.

const DataLoader: MiddlewareFn = ({context}, next) => {
  if (!context.isDataLoaderAttached) {
    context.isDataLoaderAttached = true;

    context.personLoader = new DataLoader(/* ... */);
    // ...
  }
  return next();
}

Of course you would need to provide new context object in express-graphql or graphql-yoga.

I'm not a fan of creating DI Container for each "request" as it denies the idea of single-threaded Node.js.

[ashleyw]

Is anyone aware of a workable strategy to get dataloader integrated with type-graphql today?

[MichalLytek]

@ashleyw you can always fallback to the plain apollo-like resolvers strategy - create dataloaders for your app for each request (like in example above - new DataLoader) and then retrieve them using @Ctx decorator for use in your resolvers.