A small but important finding from experience for those who want to delve deeper into actor models such as MS Orleans. IMHO, MS Orleans and Actor model in general is only suitable for scenarios where an object has a long life. For example, consider a game in which a player object must be in memory during the game, and its state is changed during the game. For most other scenarios where an object has a short life, such as a CRM, Webshop, etc... no Actor model framework is suitable. That is not what they are intended and built for.
In Akka, "actor per request" is a pretty common pattern. It's an actor that is spawned to handle a single "request" (e.g., a single HTTP call) and then terminate.
A small but important finding from experience for those who want to delve deeper into actor models such as MS Orleans.
IMHO, MS Orleans and Actor model in general is only suitable for scenarios where an object has a long life. For example, consider a game in which a player object must be in memory during the game, and its state is changed during the game.
For most other scenarios where an object has a short life, such as a CRM, Webshop, etc... no Actor model framework is suitable. That is not what they are intended and built for.
You've just simplified my life. Thank you very much. My first thought was "Oh crap, I need to learn THAT stuff either???"
@@ilyahryapko I know the feeling. That's why I put a comment here for people who have no experience with it yet.
In Akka, "actor per request" is a pretty common pattern. It's an actor that is spawned to handle a single "request" (e.g., a single HTTP call) and then terminate.