Akka.NET Actors: Async / Await vs PipeTo

[@AndreLoker]

It would have been interesting to compare async/await to a more complex approach with PipeTo including behavior switching/stashing/unstashing (to mimic suspension of the mailbox during asynchronous processing).

[@ihsanislam651]

how can we implement AKKT with nodeJS? i need this for my bots trading platform, any direction would be much appreciated

[@willemdrost9721]

Instead of using PipeTo, would it not be better to simply spawn a separate actor for each concurrent action? PipeTo seems very anti-pattern to me, it gives me the same vibes I get from the "friend" construction in C++ (where friends can touch your privates).

[@Stannardian]

PipeTo is more like an integration between the TPL (Task) APIs and actors - it takes the results of a Task and lets it get piped back into the actor's mailbox like a normal IActorRef.Tell would. If you have a really long-running Task or if you want to run several of them all concurrently from the same actor, this pattern in combination with something like behavior switching allows the actor to still be responsive to additional messages while those tasks are running

[@MladenMihajlovic]

Nice video. One thing I was totally confused by PipeTo in the beginning was what return type was being piped. In reality I was really trying to just call a DB Async method using Dapper's QueryAsync method, and I was confused if using PipeTo would somehow convert the result to some new Message Object or something (which of course it doesn't, so you would want to wrap the results into your own message type and receive on that).

[@RizaMarhaban]

Awesome!

[@dosomething3]

iho. throughput should not be an issue in your actor based system. you should have multiple actors keeping your hardware busy.

[@Petabridge]

Agree - you can solve the throughput problem by scaling horizontally with more actors. But, you can also accomplish that through running more detached tasks via PipeTo if those Tasks are simple.