How to use the GraphQL Java Dataloader?

[soudmaijer]

I am looking at how to use the java dataloader: https://github.com/graphql-java/java-dataloader in my spring-boot-graphql app. Does graphql-java-tools provide support or does the spring-boot app provide this support?

I am trying to find some documentation to glue this all together.... any help would be really appreciated!

[apottere]

Right now the data loader isn't supported by this library or graphql-spring-boot, but there's been some interest and I'm looking at how I could add support for it.

[LeeWong]

It would be awesome. When do you think this feature can be ready? Thank you.

[apottere]

@LeeWong I'd have to look at how DataLoader is implemented in graphql-java, and I haven't had time to do that yet. If you had experience I'd love to hear how you'd like to be able to use it with this library.

[szantogab]

@apottere @soudmaijer I think we should have the ability to create new GraphQL objects and instrumentations per request. I don't know what is the current lifecycle of the GraphQL object in this library, but according to this doc we should be able to specify that we want to have this object created in every request.

[soudmaijer]

@apottere As you already know dataloader is now included as a dependency for graphql-java v5.0.0. I am really curious what approach you are planning for integrating the dataloader. I was investigating a bit how this could/should work...

I create an experiment, see this gist: https://gist.github.com/soudmaijer/3fc6d32a2dad10960556a5e6ce0a5aca#file-graphqljavatoolsdataloader-kt-L21

I was first thinking about just creating a request scoped bean instance of my DataLoader class. The main issue is that after processing all simular items at a certain level in the graph, the DataLoader.dispatch() method must be invoked to fetch the real data.

In plain GraphQL java this is handled by the DataLoaderDispatcherInstrumentation. Also see: http://graphql-java.readthedocs.io/en/v5/batching.html

What are your ideas?

[oexza]

Any update on this?

[oexza]

Any update on this?

[soudmaijer]

I have a working example for you. Op 25 nov. 2017 09:47 schreef "Peace Michaels" <[email protected]>:

…

Any update on this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/graphql-java/graphql-java-tools/issues/58#issuecomment-346927539>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANyty2WNw4i70hNv2jTrtn5AnvZo-xWks5s59Q6gaJpZM4PMDVt> .

[apottere]

I don't have an update on this yet, working on subscription support then I'll focus on this.

[PaveLiArcH]

You can just provide instrumentation bean (if using graphql-spring-boot-starter)

  @Bean
  DataLoaderRegistry dataLoaderRegistry(List<DataLoader<?, ?>> loaderList) {
    DataLoaderRegistry registry = new DataLoaderRegistry();
    for (DataLoader<?, ?> loader : loaderList) {
      registry.register(loader.getClass().getSimpleName(), loader);
    }
    return registry;
  }

  @Bean
  Instrumentation instrumentation(DataLoaderRegistry dataLoaderRegistry) {
    return new DataLoaderDispatcherInstrumentation(dataLoaderRegistry);
  }

create your DataLoaders, extending base DataLoader, and use DataLoaders in resolvers.
Sample:

@Component
public class ProjectToVolumeDataLoader extends DataLoader<Integer, List<Volume>> {
  public ProjectToVolumeDataLoader() {
    this(null);
  }
  public ProjectToVolumeDataLoader(DataLoaderOptions options) {
    super(keys -> CompletableFuture.supplyAsync(() -> {
      List<List<Volume>> result = new ArrayList<>(keys.size());
      ... do some magic to fill result (using db, using slow device, etc)  ...
      ... result must be in same order as keys ...
      return result;
    }), options);
  }
}

@Component
public class ProjectResolver implements GraphQLResolver<Project> {

  private final ProjectToVolumeDataLoader projectToVolumeDataLoader;

  public ProjectResolver(ProjectToVolumeDataLoader projectToVolumeDataLoader) {
    this.projectToVolumeDataLoader = projectToVolumeDataLoader;
  }

  public CompletableFuture<List<Volume>> getVolumes(Project project) {
    return projectToVolumeDataLoader.load(project.getProjectId());
  }
}

[tototoben]

Am I correct in assuming there isn't still a good way to have request scoped DataLoaders? I am using graphql-spring-boot and after some debugging through some resolvers I ended up feeling somewhat lost.
Sorry if this is the wrong place to ask about this, I realize there is an issue raised in the graphql-spring-boot repo (#44) that is of a similar nature, but it also seemed my concerns we're already raised and left open in this issue.

[breun]

@tototoben I'm not sure what you consider 'a good way to have request scoped DataLoaders', but I'm successfully using DataLoader like this with graphql-spring-boot (manually translated from Kotlin to Java, so please forgive any syntax errors):

@Bean
public Instrumentation instrumentation(final MetricRegistry metricRegistry, final DataLoaderRegistry dataLoaderRegistry) {
    return DataLoaderDispatcherInstrumentation(dataLoaderRegistry);
}
            
@Bean
public DataLoaderRegistry dataLoadRegistry(final MyDataLoader myDataLoader) {
    DataLoaderRegistry dataLoaderRegistry = new DataLoaderRegistry();
    dataLoaderRegistry.register("myDataLoader", myDataLoader);
    return dataLoaderRegistry;
}

By the way, I had to manually override the version of java-dataloader to 2.0.2, because performance was pretty bad with 2.0.1, which comes with graphql-java 6.0, which comes with graphql-java-tools 4.3.0 (I believe because of a synchronisation issue in java-dataloader).

[tototoben]

@breun Coming back to this after two months of no GraphQL contact took some time to get in the know with the issue again, but my problem was with caching.
I have a similar configuration as you provided, but once the initial request with the dataloader is done I receive the cached value on all subsequent request, but caching should be done only within one web request.

The issue boils down to what is talked about in the java dataloader docs as far as I can see:
http://graphql-java.readthedocs.io/en/latest/batching.html#per-request-data-loaders

Am I missing something here or is this a valid issue?

[breun]

Ah ok, we disable the DataLoader cache, because the default behaviour of the java-dataloader cache is indeed to cache without expiring (until application restart) and that's way too long for us (data can change you know). You can plug in your own cache implementation based on Guava or Kaffeine according to https://github.com/graphql-java/java-dataloader#custom-caches, but indeed it is not clear to me how to have a cache per request. So far I haven't had a need for caching (services called by our GraphQL applications may do their own caching), and since upgrading java-dataloader to 2.0.2 we can serve thousands of requests per second with just a couple of nodes.

[tototoben]

Looking at it now, yeah, just disabling the cache seems like a reasonable solution, thanks!

[oliemansm]

@dinhani graphql-java-tools will pull in the supported graphql-java dependency automatically, so if you simply remove it from your own dependencies you should be good.

[NikolaiChechin]

Hey! Does anybody have ideas how to use data loaders in a proper request-scoped way with graphiql-spring-boot-starter?

[oliemansm]

You mean graphql-spring-boot-starter I presume, not graphiql? Have you checked the examples in that other project you're referring too, because there is one: example-request-scoped-dataloader

[Kotodevochka]

since currently it is impossible to use batched DataLoaders to solve N+1 query problem in graphql-java-tools, is there a way to integrate custom DataFetcher objects (which would be batched and use DataLoader) into SchemaParser provided by graphql-java-tools?
Updated: okay, actually it is possible to use deprecated @Batched annotation together with BatchedExecutionStrategy, however DataLoaderDispatcherInstrumentation seems not to work with graphql-java-tools...

[NikolaiChechin]

@oliemansm Thanks a lot! That is exactly what I was looking for.

[bonobonohu]

@parthiNM You don't have to call the dispatch methods by yourself. These methods are automatically called by the DataLoaderDispatcherInstrumentation as each level of the query executes.

You should have such kind of configuration in your code:

...
@Bean
public Instrumentation instrumentation(DataLoaderRegistry dataLoaderRegistry) {
  return new DataLoaderDispatcherInstrumentation(dataLoaderRegistry);
}

bad news, it seems - at least for now - DataLoaderDispatcherInstrumentation has no constructor which takes a DataLoaderRegistry instance.
is this a problem, or the code was refactored properly? if it is a problem, are there any solutions?

thx!

[kaqqao]

@bonobonohu graphql-java has had this instrumentation registered by default for quite a while now, no need to add it yourself

[Silvatre]

Is there any update on how to add custom DataLoader instances into GraphQL ExecutionContext in graphql-java-tools generated schema/resolvers? There seems to be no simple bean to inject into the Spring context that would provide an ability to add DataLoaders. How is batching achieved on resolver layer with graphql-java-tools then?

[bonobonohu]

@bonobonohu graphql-java has had this instrumentation registered by default for quite a while now, no need to add it yourself

okay, thanks, it seems i was on a completely bad track then! now i found this solution:
https://github.com/graphql-java-kickstart/graphql-spring-boot/tree/master/example-request-scoped-dataloader
and it just works like a charm. i refactored (back) my pure GrapQL-Java implementation back to utilize Kickstart, and experienced no issues (yet), but exactly the same behaviour.
(okay, i'm using/used it with caching disabled - using my own caching solution.)

[slavap]

@bonobonohu request scoped dataloader works for me as well. Just don't understand why you are saying that caching should be disabled? Per request scope eliminates caching problems, right?

[vojtapol]

You can pass data loader registry when building ExecutionInput:

Builder executionInput = ExecutionInput.newExecutionInput()
    .dataLoaderRegistry(myRegistry)
    .query(query)
    .context(context);

This works as expected in GraphQL Java Tools. I would advise to make sure caching is either disabled or the whole registry is recreated for each request otherwise you might see invalid data being returned from the data loader.

Please open a new issue if you have more questions.

[Bwvolleyball]

@vojtapol - it's very hard to figure out what you mean with your reference to the ExecutionInput because there is no additional context.

[vojtapol]

@Bwvolleyball The graphql.GraphQL class has .execute methods. One of the overloads takes in an instance of graphql.ExecutionInput. That's what you see in my code snippet.

[soudmaijer]

For what it is worth, I pushed a full working example to my github repo. This is working with plain spring boot 2.2.5 (no graphql kickstart needed):

https://github.com/sourcelabs-nl/graphql-java-tools-dataloader/blob/master/src/main/kotlin/nl/sourcelabs/graphql/demo/DemoApplication.kt

[pinguinjkeke]

Very good example. The only thing I'd recommend is to use canonicalName instead of simpleName

[dhitalsand]

You can just provide instrumentation bean (if using graphql-spring-boot-starter)

  @Bean
  DataLoaderRegistry dataLoaderRegistry(List<DataLoader<?, ?>> loaderList) {
    DataLoaderRegistry registry = new DataLoaderRegistry();
    for (DataLoader<?, ?> loader : loaderList) {
      registry.register(loader.getClass().getSimpleName(), loader);
    }
    return registry;
  }

  @Bean
  Instrumentation instrumentation(DataLoaderRegistry dataLoaderRegistry) {
    return new DataLoaderDispatcherInstrumentation(dataLoaderRegistry);
  }

create your DataLoaders, extending base DataLoader, and use DataLoaders in resolvers.
Sample:

@Component
public class ProjectToVolumeDataLoader extends DataLoader<Integer, List<Volume>> {
  public ProjectToVolumeDataLoader() {
    this(null);
  }
  public ProjectToVolumeDataLoader(DataLoaderOptions options) {
    super(keys -> CompletableFuture.supplyAsync(() -> {
      List<List<Volume>> result = new ArrayList<>(keys.size());
      ... do some magic to fill result (using db, using slow device, etc)  ...
      ... result must be in same order as keys ...
      return result;
    }), options);
  }
}

@Component
public class ProjectResolver implements GraphQLResolver<Project> {

  private final ProjectToVolumeDataLoader projectToVolumeDataLoader;

  public ProjectResolver(ProjectToVolumeDataLoader projectToVolumeDataLoader) {
    this.projectToVolumeDataLoader = projectToVolumeDataLoader;
  }

  public CompletableFuture<List<Volume>> getVolumes(Project project) {
    return projectToVolumeDataLoader.load(project.getProjectId());
  }
}

Instrumentation bean does not accept dataLoadRegistry..Any Alternatives ?

[matsmad]

Any updates on this?

[schneiderlin]

 @Bean
  DataLoaderRegistry dataLoaderRegistry(List<DataLoader<?, ?>> loaderList) {
    DataLoaderRegistry registry = new DataLoaderRegistry();
    for (DataLoader<?, ?> loader : loaderList) {
      registry.register(loader.getClass().getSimpleName(), loader);
    }
    return registry;
  }

just register a DataLoaderRegistry bean into spring.
DefaultGraphQLInvocation::invoke will pickup dataLoaderRegistry for you