Design question: returning Future vs passing Handler

[jklingsporn]

Good day,

I'm currently thinking about designing another software project based on VertX. What I figured out in my past project is, that the recommended way of passing a Handler<AsyncResult<X>> into any async method makes it very hard to chain those actions. One could circumvent this by either switching to the rx-api (which I'm a bit reluctant to do) or change all APIs from 

void myAsyncMethod(Handler<AsyncResult<T>> handler);

to

Future<T> myAsyncMethod();

Doing this (sequential) chaining becomes easier, like you can see in this comparison (result of operation 1 should be passed into operation 2):

//Handler Style 1
Future<T1> f1 = Future.future();
someService.myAsyncMethod1(f1.completer());
f1.compose(t1Result->{

Future<T2> f2 = Future.future();

someService.myAsyncMethod2(t1Result, f2.completer());

return f2;  

}).setHandler(h->{
//I'm complete
});


//Handler Style 2
someService.myAsyncMethod1(h1->{

if(h1.succeeded()){

someService.myAsyncMethod2(h1.result(),h2->{/*I'm complete*/});

}

});



//Future Style
someService.myAsyncMethod1().
compose(t1Result->someService. myAsyncMethod2(t1Result)).
setHandler(/*I'm complete*/);

What are your thoughts on this? Is there a drawback using Futures that I'm currently not seeing?

[Tim Fox]

Personally I prefer dealing with futures these days, although I tend to use Java's CompletableFuture not Future as below.

I use a simple adaptor class to convert between async handlers and the futures. I mentioned this in a post on this forum very recently.

The reason Vert.x core uses async handlers is basically because when I started the project it was very much modelled after the Node.js APIs which use a similar handler approach.

[jklingsporn]

You mean that one: https://github.com/Tesco/mewbase/blob/master/src/main/java/io/mewbase/util/AsyncResCF.java ?

What is the reason you prefer CompletableFuture over Vertx-Future? Interoperability with other frameworks? 

[Julien Viet]

Hi,

we had a discussion on vertx-dev about this topic a couple of months ago where we wanted to go more toward the Future style, based on CompletableFuture or CompletionStage.

We decided to leave it aside for the moment (because it was an important change breaking the API a lot, also we did not had a consensus on some technical parts) 

My personal opinion is that the current Rxified API does an equivalent job and address both streams + futures and is definitely a popular solution.

I believe this is an item we will revisit sometimes later, probably heavily discussed at the next F2F meeting :-)

Julien

-- 
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/d2484469-b96b-40c5-97c1-a91d110b2194%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jez P]

+1.

I've been working on creating an async version of the Pac4j API (ultimately to be used as the basis of a non-blocking vertx/pac4j implementation, though I wanted to build it in a way that other async implementations could easily consume) and I'm finding CompletableFutures really helpful. In my case the choice was basically Rx vs CompletableFuture and I chose the one that was already present in core Java. 

The only slight annoyance for me is that where the CompletableFuture API is doing map/flatMap semantics, it would have been nice to retain naming consistency with the streaming API rather than introduce thenApply/thenCompose as names. However, that's a pretty minor gripe, as once you get the translation in your mind, it becomes second nature. 

I've also used Rx in some of my vertx-pac4j tests and there isn't so much to choose between them other than for a general-use API I didn't want to enforce a third-party dependency at the exposed API level.

Out of interest, to the OP, what's your reluctance to adopt the rx-api based on? I'm entirely comfortable using it internally, I just didn't want to define a public API in terms of Observables (the parts which are internal are less of a concern). 

[jklingsporn]

@Julien I've been reading a bit through that thread and I agree that adding another way of handling async-methods might confuse users. Still I think that the Future-style is more fluent and readable than the rx-style and way better than dealing with async handlers. 

@JezP I don't (yet) need all the stuff that rx-java gives me. Composing and mapping as given by the vertx-future is all I need right now. Also I find it more readable, but that is a matter of taste.

[Jochen Mader]

In vertx-lang-scala I replaced all instances where a Handler<AsyncResult> is provided to instead return an appropriate scala-Future. This not only makes the API a lot nicer it also allows easy integration with CompletableFuture and Observables.

I completely agree that the futrue lies with CompletableFuture, especially when looking at our polyglot approach. The smallest common denominator for all languages is what the JVM provides.

--

You received this message because you are subscribed to the Google Groups "vert.x" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/1cf17b4f-a995-456e-a4c1-1e678186f176%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Jochen Mader | Lead IT Consultant

codecentric AG | Elsenheimerstr. 55a | 80687 München | Deutschland
tel: +49 89 215486633 | fax: +49 89 215486699 | mobil: +49 152 51862390
www.codecentric.de | blog.codecentric.de | www.meettheexperts.de

Sitz der Gesellschaft: Düsseldorf | HRB 63043 | Amtsgericht Düsseldorf
Vorstand: Michael Hochgürtel . Rainer Vehns
Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz

[Julien Viet]

I agree it’s nice to have CompletableFuture OOTB for many projects, however I don’t find its API mind-blowing (personal opinion), furthermore CompletableFuture is tighten to the ForkJoinPool by contract which can be confusing for the user.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAAn-prVn0_ByUbZXpSdx7xoa2rB-mM_ErSB3S51rq3FD78k%2B6A%40mail.gmail.com.

[Julien Viet]

I tried to opened your eyes with this commit though https://github.com/vert-x3/vertx-rx/commit/188c9066d9e84b58a07a7e1b3a04f25f0adda642 !!!

On Apr 13, 2017, at 11:17 AM, Tim Fox <timv...@gmail.com> wrote:

-- 
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/d2484469-b96b-40c5-97c1-a91d110b2194%40googlegroups.com.

[infor...@gmail.com]

Just so I'm sure I understand this thread (which is old but still relevant), are you guys thinking of eventually replacing Vertx Future with CompletableFuture?

[infor...@gmail.com]

Wait, I don't think so, having read it again.  Right?