You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: documentation/batching.md
+62Lines changed: 62 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -370,3 +370,65 @@ DataFetcher<?> dataFetcherThatCallsTheDataLoader = new DataFetcher<Object>() {
370
370
}
371
371
};
372
372
```
373
+
374
+
## Chained DataLoaders
375
+
376
+
The automatic dispatching of Chained DataLoaders is a new feature included in GraphQL Java 25.0 onwards. Before this version, DataLoaders in chains needed to be manually dispatched.
377
+
378
+
A Chained DataLoader is where one DataLoader depends on another, within the same DataFetcher.
As this changes execution order, you must opt-in to Chained DataLoaders by setting key-value pairs in `GraphQLContext`.
391
+
392
+
1. Set `DataLoaderDispatchingContextKeys.ENABLE_DATA_LOADER_CHAINING` to `true` to enable Chained DataLoaders
393
+
2. Provide a `ScheduledExecutorService` to GraphQL Java, with key `DataLoaderDispatchingContextKeys.DELAYED_DATA_LOADER_DISPATCHING_EXECUTOR_FACTORY` and value implementing `DelayedDataLoaderDispatcherExecutorFactory`
394
+
395
+
### What changed in GraphQL Java 25.0?
396
+
The DataFetcher in the example above, before version 25.0 would have caused execution to hang, because the first DataLoader ("name") was never dispatched.
397
+
398
+
Prior to version 25.0, users of GraphQL Java needed to manually dispatch DataLoaders to ensure execution completed. From version 25.0, the GraphQL Java engine will automatically dispatch Chained DataLoaders.
399
+
400
+
If you're looking for more examples, and the technical details, please see [our tests](https://github.com/graphql-java/graphql-java/blob/master/src/test/groovy/graphql/ChainedDataLoaderTest.groovy).
401
+
402
+
Note: The GraphQL Java engine can only optimally calculate DataLoader dispatches on a per-level basis. It does not calculate optimal DataLoader dispatching across different levels of an operation's field tree.
403
+
404
+
### A special case: Delayed DataLoaders
405
+
406
+
In a previous code snippet we demonstrated one DataLoader depending on another DataLoader.
407
+
408
+
Another special case is a "delayed" DataLoader, where a DataLoader depends on a slow async task instead. For example, here are two DataFetchers from [a test example](https://github.com/graphql-java/graphql-java/blob/master/src/test/groovy/graphql/ChainedDataLoaderTest.groovy):
409
+
410
+
```groovy
411
+
def fooDF = { env ->
412
+
return supplyAsync {
413
+
Thread.sleep(1000)
414
+
return "fooFirstValue"
415
+
}.thenCompose {
416
+
return env.getDataLoader("dl").load(it)
417
+
}
418
+
} as DataFetcher
419
+
420
+
def barDF = { env ->
421
+
return supplyAsync {
422
+
Thread.sleep(1000)
423
+
return "barFirstValue"
424
+
}.thenCompose {
425
+
return env.getDataLoader("dl").load(it)
426
+
}
427
+
} as DataFetcher
428
+
```
429
+
430
+
By opting in to Chained DataLoaders, GraphQL Java will also calculate when to dispatch "delayed" DataLoaders.
431
+
432
+
The default value for the time to wait for these "delayed" DataLoaders is 500,000ns (`DEFAULT_BATCH_WINDOW_NANO_SECONDS_DEFAULT`). If you like, you can configure your own batch window by setting a key-value pair in `GraphQLContext`. Set `DataLoaderDispatchingContextKeys.DELAYED_DATA_LOADER_BATCH_WINDOW_SIZE_NANO_SECONDS` to be your preferred batch window size in nanoseconds.
433
+
434
+
Note that the case, where one DataLoader depends on another DataLoader all within the same DataFetcher, is unaffected by this batch window configuration. This window configuration only changes how long to wait for the "delayed" DataLoader case, where a DataLoader depends on another async task.
0 commit comments