Aartie Saxena
Aartie Saxena

Reputation: 13

Is creating flux from a list an optimized solution for reactive programming?

I have a blocking data store, that returns the List. In order to be reactive, should I convert this list to a flux(or Mono, depending on the return value) and then process?

List has another List. Can I use Stream to process the interim value or convert this to a Flux using Flux.fromIterable?

I am trying to understand the best practices and where reactive programming would yield best performance.

Upvotes: 0

Views: 1225

Answers (1)

Toerktumlare
Toerktumlare

Reputation: 14772

So what is the difference between a Mono and a Flux?

The difference is that a Flux is a List<Mono> (for simplicity). And what is a Mono? it is something of the type T. So what does this mean in your case.

Well if you fetch a List<T> you can either put this in a Mono<List<T> or you can put this in a Flux<T>.

If you put this list using Flux#fromIterable each item in the list will sort of become a Mono and the Flux will emit that item when available.

Since you have a blocking call that returns an entire List<T> If you put this in a Mono the subscriber will get the entire list in one big emit. If it is a really big list it can put strain on the subscriber because the publisher might emit one giant list of say 1 000 000 items in one big chunk.

If a big list is put in a Flux the subscriber can limit and ask the service to emit items in a more controlled manor, for example in 10 batches of 100 000 items each.

So i personally would recommend to put the list in a Flux.

But none of this has any significant performance gain on your application. It's more a feature that calling subscribers can gain.

To prevent major slowdowns in your application it is important that your blocking calls are made using its own thread. This can be achived using the Schedulers.elastic() that will spawn a new thread for long going tasks. And then kill that thread after default 60 seconds.

Upvotes: 1

Related Questions