This is what I’ve struggled with when trying to learn erlang/elixir/gleam:
If I go all in, then modelling as actors makes sense. The domain model is modelled as in-memory actors, using erlang features for persistence and what not.
But most of the time this isn’t what we want in modern software: instead our state is in a database and we are executing in a request-response setup. This seems to be mismatched with actors, as, it seems to me, at least, you’re mapping the database states into your actors on each request and then back on response, at which point, what do actors actually buy you?
The same mismatch exists with OO too, of course, but with actors there are a bunch of benefits that you get by going all in, which it seems to me are lost if you’re simply building a database backed request-response system.
I mean, many of the OP’s pros of actors rely on actors being long lived things, rather than short lived within a request.
Maybe I’m just missing something. But maybe it’s also just not suited to typical web api backend?
a few years back i had one side project that i did in elixir/phoenix felt like a good fit specifically because it had a lot of state that needed to live outside of the request/resp cycle but also didn't live in a db
Specifically the project was an app that ran terraform commands inside an actor and streamed the logs to the browser
each actor had a terraform config and each message was a command to run on that config
so in that case the actor model felt like it aligned really well with how the program needed to work
If I go all in, then modelling as actors makes sense. The domain model is modelled as in-memory actors, using erlang features for persistence and what not.
But most of the time this isn’t what we want in modern software: instead our state is in a database and we are executing in a request-response setup. This seems to be mismatched with actors, as, it seems to me, at least, you’re mapping the database states into your actors on each request and then back on response, at which point, what do actors actually buy you?
The same mismatch exists with OO too, of course, but with actors there are a bunch of benefits that you get by going all in, which it seems to me are lost if you’re simply building a database backed request-response system.
I mean, many of the OP’s pros of actors rely on actors being long lived things, rather than short lived within a request.
Maybe I’m just missing something. But maybe it’s also just not suited to typical web api backend?