Posted by liqweed:
Support asynchronous query execution by creating DgraphGrpc.DgraphFutureStub instead of DgraphGrpc.DgraphBlockingStub.
We use GitHub - lukas-krecan/future-converter: Converts between various future types to to convert Guava’s ListenableFuture (the existing Java gRPC implementation) to Java 8’s CompletableFuture.
deepakjois commented :
I am finding it a bit hard to understand some of what you said. Maybe it is because we are not really that familiar with Java on our team.
I realise that we force the users of this client to use DgraphGrpc.DgraphBlockingStub, which takes away the choice of using the asynchronous grpc client. Ideally we would like the user to choose what they want. But at the same time, we don’t want to have repetitive code to support both clients.
It sounds like you are suggesting that we could use this Future Converter project to acheive that, but I am not able to follow exactly how that would work. Could you elaborate if possible?
liqweed commented :
You could always provide a sync client that delegates to the async client and then blocks on the CompletableFuture responses (calling get(...) with reasonable/configured timeouts).
I’ll push a pull request to that effect.
manishrjain commented :
@liqweed : Were you planning to send us a PR?
liqweed commented :
I’ll refork and give it another try in a couple of days.
piyushGoyal2 commented :
@liqweed /@deepakjois @manishrjain : This is what we need as well. Our framework for microservices with backend as Lagom doesnt recommend us to use blocking database calls due to which the other option is to create an executor and delegate the db call to other threads. Had the response of DGraph be in ListenableFuture/CompletableFuture life would have been much easy.
Hoping to get this patch soon.
deepakjois commented :
This is now done as part of #60