Is grouping too much? about smallrye-mutiny HOT 7 CLOSED

@zeljkot @jponge just added filter: #157

from smallrye-mutiny.

@cescoffier I have read the discussion in issue #1
I'm a very beginner user of Reactive API to be honest and I haven't a very strong opinion.
That said, I think I prefer a less fluent API, so the 2nd choice.

from smallrye-mutiny.

I was chatting about this to @cescoffier and I mentioned I felt the former was more flexible, but the latter easier to read.

If there was a way to offer both, that would allow both use cases.

from smallrye-mutiny.

@FroMage, @vietj, and @ebernard had a chat yesterday.

Basically, there are a few alternatives:

1. Flat structure like RX and Reactor:

• - too many methods, IDE completion not useful (we are talking about 400 methods with many overrides)
• - not really usable by non-reactive / functional developer
• + like RX

2. Adding options, like:

uni.onTimeout(new TimeoutOptions().of(ofHours(1)).fail())
multi.onResult().flatMap(mapper, new FlatMapOptions().withConcurrency(2))

• - IDE does not guide you for the options
• - duplicate all methods for the one with sensible defaults
• + avoid most of the subgroups
• - does not fix overloading like: flatMap vs. flatMapUni vs. flatMapIterable

3. Flatten group as follows:

`onResultApply(Function<I, O>)` // map
`onResultMerge(Function<I, Multi<O>>)` // flatMap
`onResultConcat(Function<I, Multi<O>>)` // concatMap
`onResultMergeIterable(Function<I, Iterable<O>>)` // flatMap iterable
`onResultCompose(Function<I, Uni<O>>` // flatMapUni

• - Different wording
• - Lots of method on Uni/Multi
• - Missing fine-tuning (concurrency, scheduler...) as we would need to avoid overload

from smallrye-mutiny.

I've got one more thing to add to this topic, which I was finally able to put into words after quite some time of feeling "there's something wrong but I'm not sure what exactly":

This looks like a fluent API, but isn't.

It might sound obviously wrong, but the thing is: this is not a fluent API; it is two fluent APIs mixed into one. On one level, we have a fluent API for building the data pipeline. On the other level, we have a fluent API for configuring each stage of the pipeline.

(In addition, all the .onEvent().doSomething() looks more like an event dispatcher instead of a pipeline. Yet it's still a pipeline. Not a fan.)

from smallrye-mutiny.

For common, well-established method I would provide first-level methods. This is already done for the map and flatMap. Writing onItem zillion times makes code less readable because almost every line starts with onItem() and then you must look for the real operation.

I would also shorten .transform().byFilteringItemsWith() to .filter().

For the less used things, I like the 2nd level. It keeps the first level clean.

from smallrye-mutiny.

Closing - out of date.

from smallrye-mutiny.