I apologize for the title. I found it hard to describe this problem in a few words.
I currently have a system build upon actors, each containing a FRP world (similar to scala.rx).
In each actor, some variables can be modified by sending messages to it. Conversely, some variables are observed and messages will be sent when they are triggered (then triggering changes in other actors).
By doing this, I can connect these synchronous actors with each other. However, this introduces the problem which I’m trying to solve: back-pressure.
To solve this, I thought I’d take a step back and rebuild this with akka-stream.
Should I put each FRP world, which now exists in actors, into a GraphStage? Or perhaps I should use streams to communicate between actors?
The only way I’ve came across communicating between actors seems to be one where I must send an ack for each message - that impacts performance heavily.
You might also be interested in Stream refs, if you need streams over the network.
That is not the only way. You can use the work pulling pattern by requesting more than one item, or acknowledging more than one item. I have created an example of that.
I looked into your suggestions and it seems most suitable for me to keep using actors. However, I still wish to use akka-stream for communicating between FRP worlds.
The example you sent does not use akka-stream. Would it be easy (and make sense) to combine the two?
Some input/output vars are intended to be consumed/produced in other places (e.g. synchronizing state over WebSocket). Other inputs/outputs are intended to be rate-limited, not necessarily by the producer.
So I think my question boils down to: how I can make actors with (conceptually) multiple streams between each other, each stream having customizable throttling/rate limiting?
Some of the different FRP worlds will be on other machines, and then it would become even more important to have a request window rather than sending acks for individual messages.