I'm aware that as of Akka 2.4.16, there is no "remote" implementation of Reactive Streams. The specification focuses on a stream running on a single JVM.
However, considering the use case to involve another JVM for some processing while maintaining back pressure. The idea is to have a main application that provides a user interface running a stream. For instance, this stream has a stage performing some heavy computations that should run on a different machine. I'm interested in ways to run streams in a distributed way - I came across some articles pointing out some ideas:
- Connecting streams via TCP using Akka HTTP (Stackoverflow)
- Simplifying it with Artery to a certain extent (Stackoverflow, Akka Blog)
- Integrating actors into a stream (Answer from Viktor Klang, Akka Docs)
What other alternatives are there? Are there any significant downsides to the above? Any special characteristics to consider?
Update: This question is not limited to a single use case. I'm generally interested in all possible ways to work with streams in a distributed environment. That means, e.g. it can involve only one stream that integrates actors with .mapAsync
or e.g. there could be two separate streams on two machines communicating via Akka HTTP. The only requirement is that back pressure has to be enforced among all components.
Well... It seems that I will have to add an example for that. One thing that you need to understand is that BackPressure is handled by the AsyncBoundries in GraphStages. It really has nothing to do with a component existing some where else. Also... It is not dependent on Artery which is nothing but the new remote transport.
Here is an example of probably the simplest cross-jvm stream,
First Application,
And Second application... actually "runs" the stream which uses the actor in first application.