Rxified Service Proxies about vertx-service-proxy HOT 10 CLOSED

For lack of a better example, let's assume we have a ProductService. While the client can interact with an Observable, the server (ProductServiceImpl) has to deal with methods like this:

public void find(String customerId, Handler<AsyncResult<List<JsonObject>>> resultHandler) {

So when implementing a service in order to provide events (actually just one) to the subscriber, I would have to deal with the resultHandler. It would be much more convenient to implement a method like this:

Observable<List<JsonObject>> find(String customerId);

That way I can invoke multiple downstream services in parallel, flatMap, merge, zip and aggregate, filter,...without having to deal with Handler<AsyncResult<List<JsonObject>>> or callbacks. Having both callbacks and Observables is not what we want.
Note that I would not have to subscribe on the Observable. That could be done by the generated Proxy.

The limitations of the second point: Mocking/Testing, AOP-Proxies, Dependency Injection.

Hope this helps to understand my POV.

edit: maybe my terminology is off.
By 'client' I mean the message sender, possibly a verticle running in another vert-instance sending messages via the generated rx-wrapper facade. 'Server' refers to the message recipient. So I would see the service interface, rx-wrapper and *EBProxy as part of the client lib and the {Interface}Impl class as the server.

from vertx-service-proxy.

I think we should be able to generated an Rx version of the original service proxy interface that would provide hooks to implement it using RxJava, something like

interface Service {
   void foo(Handler<AsyncResult<String>> handler);
}

generates

class RxServiceAdapter implements Service{
   public void foo(Handler<AsyncResult<String>> handler) {
      // generated code that calls rxFoo()
   }
   public abstract String<String> rxFoo();
}

would that help ?

from vertx-service-proxy.

you can already use services proxies with Rx, look at this example with JDBC:

https://github.com/vert-x3/vertx-examples/blob/master/rx-examples/src/main/java/io/vertx/example/rxjava/database/jdbc/Client.java

from vertx-service-proxy.

so actually this is valid, it is just that we don't generate yet an rx version for mongo, I will add it

from vertx-service-proxy.

now it exists : vert-x3/vertx-mongo-client@2c9f0a1

the correct issue tracker would have been the vertx-mong-service project itself and now you have

public Observable<String> insertObservable(String collection, JsonObject document)

from vertx-service-proxy.

Hi Julien,

thank you for your quick response. Your average response time is faster than my last project's JEE-Server. ;-)

My question was not specific to vertx-mongo, but I will gladly use the new snapshot. Apparently I missed the VertxGen-annotation so no rx-wrapper has been created.

Unfortunately the generated wrapper object has a few drawbacks:

• While the wrapper improves the situation on the client side (clients can now use the rx-proxy), the server side (e.g. MongoServiceImpl) still has to deal with callback-hell. My service performs calls to other "services", aggregates and filters results. That's really painful without rx-support.
• I am now bound to a concrete implementation rather than an interface. That really puts some limitations on how we can use the proxy.

from vertx-service-proxy.

On your first point, the implementation of the server side (MongoServerImpl) can use whatever it wants. I don't see the relationship with Rx. Can you explain with more details ?

Second point : we generate a class from an interface, the generator work this way. We could have generated an rx interface and an impl too. We chosed a class because the interface does not add much. Can you clarify what you mean by "limitations" ?

from vertx-service-proxy.

Hi,

I would also be happy to see the feature like michaelom desciped it.

thx

from vertx-service-proxy.

I would also be happy to see the feature as @michaelOM mentioned also, I want to write a pure-rxjava project. Mixing up with Future and Observable is not a good idea...

from vertx-service-proxy.

Struggling with this, would like to see it in place.

There is RxHelper in Rx Java1 that can do this:
ObservableFuture<> foo = RxHelper.observableFuture();
service(foo.toHandler());

But not in RxHelper in Rx Java2. Is there alternative?

from vertx-service-proxy.