CODEWITHSUNDEEP
javareactorrx-java
Aravind Yarram
Aravind Yarram

Reputation: 80166

Can I benefit from a reactive library in this scenario?

App 1 sends request to App 2. App 2 performs the following steps and returns the response to App 1. I am wondering if App 2 can benefit from using reactive libraries like RxJava, Reactor etc. If so, please explain how?

  1. Send the HTTP Post requests to all the 7 data source services
  2. Wait for the responses from them and parse all the responses
  3. Merge all the responses
  4. Return response to App 1

enter image description here

Upvotes: 1

Views: 1027

Answers (1)

Jon Brisbin
Jon Brisbin

Reputation: 741

This is about as classic a use case for reactive libraries as you might find! :)

The key part of "reactive" architectures is that they can respond to events rather than wait for results. RxJava facilitates this via Observable and Reactor does this via several different mechanisms. In Reactor, you can use a plain Reactor and set a replyTo on the Event, you can use a Stream or a Promise to compose a chain of processing on values much like RxJava's Observable, you can use a Processor to do high-speed RingBuffer processing, or you can use a ForkJoinPool for doing simple fork/join style processing. That's a lot of options, for sure, but each one is designed to work in a particular use case without compromising for other use cases. Reactor the framework isn't a single, adjustable wrench. It's a set of wrenches sized exactly for what you need.

In this particular case the important part is the parallelism achieved by doing lots of work concurrently since your datasource IO is presumably blocking the thread. RxJava has a pluggable execution model but it's fairly coarse-grained. One of Reactor's strengths is the efficient, fine-grained task dispatching support and the ease with which you can react to results.

Since your use case is pretty straightforward and much closer to a standard ThreadPoolExecutor situation, I might be tempted to use the ForkJoinPool in Reactor 1.1 (which is brand new). The ForkJoinPool provides you with a single Promise<ImmutableList<T>> that joins the results of all the tasks you submit to the pool, which is backed by a standard ThreadPoolExecutor. It's basically a "reactive" wrapper around a standard thread pool so requires very little overhead but provides the flexibility of reacting to the completion of all submitted tasks. It's similar to RxJava's Observable.merge().

Upvotes: 4

Related Questions