New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Java port #26
Comments
Hi @xak2000 did you go any further with this? For Java you can take a look at Vert.x from Eclipse at http://vertx.io/ |
Hi, @aschrijver. Thanks for your involvement! Yes, I know about Vert.x, but Vert.x is a "container" for your applications (verticles). It is very good project, no doubt. But I wanted to implement just pure Java solution, without dependencies. It is straightforward to implement DataLoader in Vert.x (because of async nature of Vert.x and it's EventLoop), but then it will be usable only inside Vert.x application. As for pure java implementation.. Now I don't have time to do futher investigations, but I think it is just undoable, sadly. :( Because there are no eventloop, we just can't know when to run a batch load function for all scheduled loaders. There are two options as I see:
I don't really like any of this solutions because they lack of gracefulness of original idea of DataLoader - non-intrusive automatic batch loading. Maybe combine this two solutions into one (shedule batch function to run automatically, but allow to run it manually if user knows when) can give a more or less acceptable result... |
Vert.x does not have to be the container for your entire app. You can also run it embedded without exposing to clients. You only ship the transitive dependency on |
Yes, you can run Vert.x embedded, but it is still a container (embedded into your application, but still a container), and DataLoader implementation based on Vert.x eventloop would be usable only from code runned from this embedded container, not the rest of the application. So embedded it or not it doesn't matter. You still can't write pure-java solution which can be used in any java app as a library (not as a framework component). |
Gave some advice on #30 that's relevant here |
Hi @xak2000 , @antmdvs But your options above, while less elegant than auto batching, still make it a useful utility I think. Additional options could be to have a maximum batch size after which stuff is dispatched automatically, regular intervals (in Vertx by setting a timer), or by a custom strategy an implementer plugs in. I am writing a remote service proxy for a GraphQL schema, and intend to write a In many use cases the dispatch call can be automatically triggered, e.g. by setting it in Vert.x. on the Another interesting use I am thinking of is to implement the data loader with an asynchronous, cluster-wide map implementation (an |
BTW, what is funny to mention is that while data loader with the tick concept in NodeJS does not impact its asynchronous behaviour (correct?), in Vert.x it limits it slightly by being more of a delayed execution thing. |
I would caution against using the delay to pick up the requests in a batch. I've seen that approach used before and it can introduce real latency into your system. For JS environments that don't support the Promise queue, this timer approach is used, but the delay used is "0ms" which in the case of JS schedules for the immediate next tick of the event loop. |
Thanks, this is something I will mention in the docs, just like you did with HTTP request scope, etc. I will have code up in a couple of hours at https://github.com/engagingspaces/vertx-dataloader BTW many bunches of thanks for creating the test coverage. It is boring to translate to Java, but helps real well. I will mention you in acknowledgements section of README, if you don't mind |
Code is there now. |
@leebyron I documented the change in the Java implementation very clearly (I hope) in vertx-dataloader/manual-dispatching I think the change doesn't diminish the power of the utility in any way. On the contrary it does give additional and fine-grained control of batching and dispatching logic. |
Hi @aschrijver! Very glad to see you wrote some code! I'm opened this task, but I'm very busy now and can't give much effort to this task. One question from a quick glance to the code: does it support many-step-loading?
The problem is that Ok I think now the example is slightly incorrect. And even if we will use second Maybe I understand something wrong, but when I considered the possibility to implement Edit Something like this in GraphQL, if i wrote this correctly:
|
Hmm, yours is an interesting case to investigate further. In general with manual dispatching being the exception the implementation should be exactly identical to its counterpart in NodeJS. I still haven't ported all tests, so you have to take me on my word here. Just like the manual dispatching makes it necessary to invoke In future I will add features that will flush the queue after a When you call On your last point I documented the benefits you still have even with manual fetching (and some additional ones) in the differences to reference implementation section as well. |
If you have the time later it would be nice if you created a PoC project or a Gist to test-drive your use case! |
Forgot to mention that the preparation stage of the data loader lifecycle (i.e. adding load requests to the batch queue, from loader instantiation to just before dispatch) is usually very fast as long as no code blocks the event loop! In Vert.x every invocation is asynchronous by default, and if it is not it should be assigned to a worker verticle that runs on a thread pool (regular verticles always run on the same thread so you can regard them as single-threaded and reap the rewards of that simplicity, but you probably know this as its the main selling point of Vert.x, besides being clustered and polyglot, and modular, and... much more goodness, that is 😄 ). |
I have created engagingspaces/vertx-dataloader#3 on the Vert.x DataLoader project for this use case. |
Closing this issue since there's now a project and discussion to take this further. |
For anyone interested: Pure Java 8 implementation exists now. |
yes! that version was derived by @bbakerman from my vert.x implementation and has all vert.x dependencies removed :) |
I'm very impressed by DataLoader and trying to port the DataLoader into Java world but I got stuck with this.
If I understand correctly, the key principle of DataLoader is JavaScript eventloop. It can automatically determine when to run batch function just by adding it's execution on next tick.
But in Java there are no evenloop or something similar. The loader code just can't know when to run this batching function.
I tried to do something with
CompletableFuture
but with no luck. It doable but only with manual execution of batching function of all loaders which were used to load something.Something like this:
I just want to ask for suggestions. I know this library is port of Haxl library for Haskell, but I know nothing about haskell. It has an eventloop too? Or maybe there's some other way to implement this that I can't see?
If this repo is not suitable for this kind of questions (I understand it's Java and not JS) then I apologize. I'm just hoping that maybe someone has already tried something like this or suddenly the DataLoader's author knows java. :)
The text was updated successfully, but these errors were encountered: