Hello,
I’m new to reactive programming, the actor model and the challenges faced in concurrent systems.
From my understanding, pure actors should be used when there is concurrent access to a shared state in a complex system. It is a way of abstracting this complexity in a way that you can don’t have to deal with low level details.
Streams on the other hand are built upon actors, and deal with common challenges in actor models, like backpressure. They are a higher level API and useful for data transformations.
Now I want to build the following simple flow:
a) I need to retrieve data from an Azure Service Bus (there is a component in Akka.Streams I am aware of)
b) a part of this data is used to send a request to an external API (which can fail, obviously)
c) when the response was successful, the entity I receive should be transformed (this happens inside the application, I don’t talk to external services here)
d) when the transformation is successful, I want to forward that entity to another API.
the requirement is that no message received from the Service Bus should be lost, if step b) or d) does not work, I need to try again later, after some number of tries, I want to persist/log that data.
What am I missing to decide between actors vs Streams? I have a rough idea of what they are for, but cannot yet make an informed decision.
Hi @Empyreans Akka dot net is a completely separate project from Akka. For more Akka dot net- specific parts of your questions I recommend that you try asking in their forum instead: akkadotnet/akka.net · Discussions · GitHub
The decision between actors and streams is not always obvious. As you say actors are good for handling state in safe ways in the face of concurrency, but it can also make sense to model less stateful things, or things with implicit state as actors, for example a task with a timeout could be an actor, where the timeout is the implicit state.
It is also possible to model stateful things with streams, for example using the statefulMap operator.
I think a good way to figure what could be a good fit, other than what may suit your taste, is to think about your problem and see if it is more like a stream of events, processing a queue, or feed of some kind where the stream APIs would fit very nicely, or more of like a state that could accept interactions/commands and queries from many different other components in your system, possibly on different cluster nodes, where an actor would be a better fit.
I would like to choose akka stream now adays, because it give me more elegant result. both akka typed and untyped code will result code that’s not easily to understand, especially then the pipeline is complex.