cloudstateio
Connecting to CloudState Actor System
Hi,
Is it possible to connect to the actor system that is being used for the cloudstate? I was wondering a scenario that I can use an already existing codebase that is written with Akka and Akka stream to connect to the same Actor system and communicate with cloudstate.
Hi @omidb Would the idea here be to have access to ActorSystem? If so it would be easy to implement because it would expose the actorySystem property of the CloudStateRunner class of the java-support / scala-support module. Now if the idea is to communicate via the Actor model similar to Dapr's Virtual Actor, I think it would be much more complex to implement because we would have to expose a new api via Actor Remoting (which is interesting as another transport option besides gRPC, HTTP, and Eventing that we already support). Regarding the first case, I think it would be interesting in the java-support library to have an accessor method for ActorSystem.
I am not qualified to say which one is needed. But the goal for me is to have a connection to the existing code base and enabling developing using CloudState alongside the other existing projects. Maybe using Eventing (if it is what I think it is) we can connect to Actor systems via Kafka. It would be quiet interesting to see the best practices to adopt CloudState in an already existing codebase.
If it makes any sense, I can even think of a scenario of having Cloudflow to have an Ingress/Egress connector to a CloudState system (via Eventing or same Actor system).
The general recommendation will be to have your Akka and Cloudstate codebases as separate services, and communicate using gRPC, HTTP, or eventing, rather than actor messaging. Best practices on building microservices with Akka Cluster described in the Akka docs here:
https://doc.akka.io/docs/akka/current/typed/choosing-cluster.html
Note that Cloudstate eventing doesn't currently support Kafka (as discussed in another issue).
Agree with @pvlugter, you don't "connect to an actor system" from a different service, this would be like a Kakfa client trying to connect to a Kafka broker via its backend port that other nodes in the same Kafka cluster connect to - that port and protocol is not designed for integration with other things, it's designed to be an opaque internal communication channel between nodes of the same Kafka cluster. Instead, Kafka nodes offer a public interface that clients connect to.
The same goes for Akka/Cloudstate instances, you would never connect directly to the Akka remoting port, that port is for internal communication between nodes of the same Cloudstate service, the protocol spoken is completely internal and not documented anywhere and can change at any time. Instead, you connect via the services public interface, ie, the gRPC interface that a user function presents, and speak with it that way. In that case, it doesn't matter whether a client is another Akka based service or a browser or a service implemented in another language, they all speak the same public gRPC protocol.
