Actor Clustering / Distributed workflows

[tmihalicka]

This library shows great promise as a replacement for Akka within the Cats ecosystem. However, one key feature is missing: Actor Clustering and a mechanism for distributed workflows.

Is there any plan to implement clustering in the near future?

Another key feature which I missing is persistent actor, is there any plan to implement this feature as well?

[cloudmark]

We are not currently working on clustering, but the cats-actors are designed in a way that won’t hinder or complicate the implementation when the time comes.

Implementing persistent actors should be relatively straightforward. The preStart method is of type F[], allowing you to connect to a database and enable this flow. Similarly, there is a postStop method of type F[] to handle cleanups before the actor stops. If you provide me with a sample of what you’re trying to achieve, I can look into it.

Feel free to contribute to both of these issues—it would be great to have more contributors to the project.

[cloudmark]

Perhaps I could also do a special ask which exposes the underlying deferred so that the caller can decide what to do

[stockstock2006]

It's too much pressure to achieve functionality at the level of Akka or Pekko. Perhaps we can create a simpler version of the clustering workflow?

[jducoeur]

Personal opinion: the killer app of Akka / Pekko is Cluster Sharding -- it's the primary reason my own company is built around Akka. Clustering on its own doesn't matter that much, but reliable cluster sharding is the primary reason I care about Actors at all: it's still arguably the best approach for serious CQRS / Event Sourced architectures.

(I totally agree that this is hard stuff, and have no intention of downplaying that. Just mentioning that, from my POV, that's where the primary value is. Take that data point as you will.)

[cloudmark]

Hello @stockstock2006 and @jducoeur,

Thank you very much for sharing your thoughts and perspective. I completely agree that cluster sharding would be an excellent feature, and I’m certainly open to considering different approaches. Could you share a bit more about what you have in mind?

At the moment, my time is a bit constrained, but I would be more than happy to collaborate on this to see it through. We’re currently working on a few adjustments to the FSM to better align it with our workflows, and we expect to release these updates either later today or tomorrow.

[jducoeur]

I don't have much concrete to add, and I'm not really pressing here -- the odds that I'm going to have time to even bring Querki up to Akka 2.6 in the next year, much less go beyond that, aren't good, so in practice it's likely to be an annoyingly long time before I could consider switching here.

So this is mainly an observation that Cluster Sharding is a particular sweet spot for this technology. Most other use cases are better handled with streams nowadays IMO, but there aren't a ton of great event-sourcing solutions out there, and it fits very natually with Akka. Far as I can tell, it's pretty central to Lightbend's business by now.

(Admittedly, FSMs are probably another sweet spot. I've just never really used them much myself -- while my Actors are of course stateful, they mostly don't have the same concept of structurally distinct states.)