How does using Play Frameworks Enumerators, Iteratees, and Enumeratees, compare to using RxScalas Observables, Subscriptions, etc… for asynchronous data flows?
In what type of scenarios would you choose to use RxScala, and when would you choose Play?
If you had big data flowing through your stream would that affect your decision?
It depends what you want to do. Iteratees shine if you want to do combinator style parsing. They are really simple - they have one method called fold, everything else in iteratees, enumerators and enumeratees are just things that invoke fold. But for many, that functional approach to stream processing is too much of a mental investment to learn them, so more imperative approaches such as RX may be more suitable. Play itself is moving to Akka streams for this very reason.
The question is interesting because it compares two totally different ways of doing the same thing. I have been researching about the differences of those libraries in a project with Martin Odersky at EPFL.
Note that this work has been done before Play moves to Akka streams, so James Roper's response is good when we look at now and the future. However, as you are really asking about differences between the two, I can try to give an insight here.
Rx is easy to work with if you are comfortable with object-oriented programming (which most of the time is the case). Play iteratees come from the purely functional world (see Haskell Enumerator and Iteratee) and are less intuitive. The writing of the same application is thus very different. However, a mapping between Iteratees and Observables can be done (see GitHub link below). But it has its limit.
The main problem we can identify is that Iteratees support back pressure natively and Observables don't. Indeed, if the data flow is too big, Rx will store data in the object (i.e. on the stack). This can lead to memory problems quickly in this context. However, as Iteratees are purely functional, each piece of data will be consumed by a function in a folding operation. In that sense, the second element cannot be given to the Iteratee if the first one has still not be consumed (the function still doesn't exist !). This is what we call back pressure, because the data producer has an idea of the consumer rate and the flow rate problem is propagated back to the data producer.
As a conclusion, if you are totally comfortable with both libraries and you want to choose between the two, you may consider the purpose of the applications. If you will never have big flows, you can use Rx. In the other case, I would recommend to use Iteratees.
It would be interesting to have an idea about back pressure in Akka Streams. Natively, as it is a message passing library, the problem should be the same as with Rx. However, there seems to be interesting work in the domain, like this article that circumvent the problem using TCP.
Have a look at the GitHub or at the full paper here : Observables for Play!
