Feature EitherFlow

[gabfssilva]

Not sure if it's useful to other people, but, for sure it's a nice feature to choose two flows based on the element value (of an Either, of course).

[johanandren]

You may find this issue over in akka/akka interesting: akka/akka#25578

It could also cover the either scenario, although without any type system guarantee that you cover all subtypes of an ADT

[gabfssilva]

Indeed. But I guess it only applies if your scenario is based on polymorphism. It also relies on reflection, I don't know if I like the idea very much. =( haha
I also thought to use pattern matching to direct to the right flow, somehow like flatMapConcat, but without the need to return a new source, like:

val flow1: Flow[Payment, UniqueResult, NotUsed] = ???
val flow2: Flow[Exception, UniqueResult, NotUsed] = ???

queueSource
  .map(somethingThatReturnsATry)
  .viaMatching {
    case Success(_) => flow1
    case Failure(_) => flow2
  }
  .map { result: UniqueResult =>
    //yey =)
  }

[johanandren]

Having that not materialize the flow each time would probably be very surprising, which is why partition looks how it looks with an identifier for the downstream to choose for a given input. The alternative, to materialize a new flow (the selected one) for every element, will be expensive.

I think that case is interesting though, and I think the builder idea could have an optional transformation as well to extract the inner value from different types.

[gabfssilva]

I'm wondering, if I already have the downstream flows created, how expensive will it be to just redirect to the specific downstream flow based on each materialized value? For me, the expensive part would be to create a new source/flow for each materialized value (like flatMatConcat), but, it's not the case, right?
How expensive would it be and what do you mean by "surprising"?

[johanandren]

You have to somehow upfront materialize the Flow (which you can only do by attaching both a source and a sink to it and create a RunnableGraph) so that you can backpressure if any of the downstreams are backpressuring (since you can't know the type of the next element coming downstream and if that can really be emitted downstream) and then you have to identify running downstream flows based on the blueprint they were created with.

Not sure what you mean with "for each materialized value", there's no materialized values at play here as far as I can see, just the elements in the stream and which stream they should be sent to.

[gabfssilva]

Sorry, my bad. Not the materialized value, I meant the elements.

I think I get what you meant.

There's no way to generate the blueprint using something like viaMatching?

[johanandren]

There's no way to generate the blueprint using something like viaMatching?

I haven't seen or figured one out a reasonable way to use a partial/total function to select and lay out the stream up front at the same time. Which is what led me down the builder path.

[hochgi]

@gabfssilva Have you seen PartitionWith?

[ennru]

This behaviour could even be achieved with an alsoTo and two collectType operators.

[gabfssilva]

@hochgi sorry for the delay and yeah, I did, I just wanted to achieve the same behavior without GraphDSL. :)

@ennru It works when you want to send to a sink or if you want to filter the elements out of the stream. The proposal here is to direct the element to the right flow based on the type and not filter any element out.

I guess the closest things that achieve the behavior I want is the @johanandren proposal, but, again, it relies on reflection and has no capabilities to do exhaustive pattern matching in order to avoid message loss.

I figured since Either is such a common ADT it'd make sense to use something like it to redirect the elements.