When to use a Multi or Uni<Collection>?

[kjq]

Coming from the Project Reactor world, everything was delineated by Mono or Flux (or maybe it was more how Spring did it). Collections were generally returned as Flux. Comparing this to the Mutiny documentation, and from what has been explained to me, it looks like Uni<Collection<?>> is used more frequently.

Is it wrong to use Multi when returning a collection (especially if I don't know what the size is and/or expect the results to be large) or should I try to use Uni< Collection > where I know there is a finite size (maybe huge)?

A specific scenario in my case is I have a REST service, which makes multiple calls to different REST clients, each one a "query-like" service providing data. These results should be finite but could be considerably large and/or retrieved and returned differently which may introduce additional mechanics to control (throttling, retry, etc.).

As an example of three "external" services called individually but returned as a single Multi from the entry service:

• Query an S3 bucket file-by-file and returns the results (and actually returns the data as a future from their side)
• Query a CSV and return those results
• Invoke a WebService, which is not very stable, and return the collected paged results (based on the Mutiny paging example but in my case the beer service is a SOAP call which can be paged)
• Query a MongoDB and returns results

Because of the "size" of the results, hundreds of thousands of records at a minimum, and each service varies in approach to retrieval/returning (like latency) would these still be better suited to return Uni?

I can understand returning back an Uni but my immediate concern is that the size of the collection exceed available memory it is is collected and returned as a whole.

This references a ticket I had filed on Quarkus and this discussion

[kjq]

In trying to work through my own question is this a better understanding of an appropriate use of Multi vs. Uni<Collection<?>>?

I have a REST endpoint that will call a service (which may in turn internally call a REST client).

If this is accurate (from StackOverflow answer): then my REST endpoint is upstream and my service is downstream.

               upstream          downstream
source <--------- operator -----------> consumer/further operators

Because my service usage and characteristics may vary those can be a Multi<?>'s but at the endpoint it would be an Uni<Collection<?>> (and collect the results into a list) since it is returning a single result.

[cescoffier]

It's a great question! The answer is "it depends".

It depends on whether your remote call returns a single object or a (potentially unbounded) sequence of objects.

The simple case is when you receive a single object (T). In this case, use Uni<T>.
If you receive a sequence, It depends if that sequence is returned in a single batch or multiple. In the first case, it's better to use Uni<List<T>>. It would avoid the ceremony to create a Multi from something already in memory. If, however, it's a stream (bounded or not), in this case, it's better to use Multi<T>, as you would be able to start processing the first `T's while the next ones are still in transit.

[mklueh]

@cescoffier Thanks for the clarification. I was looking for an answer when to use what, after trying to move from Hibernate Panache to Hibernate Reactive Panache in my Quarkus project.

The documentation is only using Uni, so I was confused when to use Multi instead, when dealing with lists.

In my case I need to transform each entity and map it to a dto. Using Uni, I'd need to unwrap the result at some point, create a new stream and convert each element, returning a list of all as a new Uni, while when using Multi, I'd already have a stream of single elements.

Would you in this case recommend using Multi over Uni?

[cescoffier]

There are two approaches:

1. You can use a Multi, however, it will just wrap an in-memory collection. You can create the Multi using: Multi.createFrom().items(list))
2. You can use the Java Stream API (list.stream()) which would make the unwrapping almost invisible.