Protoactor Go project positioning and future plans?

[aschrijver]

I recently bumped into proto.actor and very interested in the Go parts of the project. But I have some questions..

Recently the DotNet project seems more active. They are independent codebases. How are they related, i.e. kept in sync functionality / compatibility wise? Is Golang part of the long-term roadmap of proto.actor as something with prolonged commitment / support?

Related: The documentation is mostly focused on C# .. is Golang the 2nd-class citizen?

How does Asynkron fit into the picture? What is your revenue model and relationship to proto.actor as an open-source project?

Related to #343 and #307

---

OT: I will also tell you a bit about the use case I am interested in, namely "easing federated app development for the Fediverse". If you find it interesting to discuss this in more detail, I can move to a separate issue.

W3C AtivityPub Recommendation is an actor-based protocol that allows federated communication based on a simple HTTP API where Actors (Person, Organization, Service, Application) exchange JSON-LD messages via inbox & outbox endpoints. This extensible protocol is the basis of the Fediverse where a large number of diverse apps interoperate and more than 5 million users interact.

It makes sense for a federated app to be actor-based internally as well, where server-to-server messages are handled by a Federation actor and delegated to e.g. Person actors referenced in the message. In my app design modularity and extensibility are key, and I intend to use domain-driven design ports & adapters architecture (similar to ftpgogo example project).

I won't be using gRPC over the network (where I use AP), but was intending to use Hashicorp's go-plugin (which uses gRPC) to have a dynamic plugin system and ability to add/remove module extensions dynamically at runtime. I still need to check if/how this can be combined with proto.actor (Proto.Remote?).

As for where DDD kicks in, I feel most for Alexey Zimarev's approach to have actors in the application layer and keep the domain layer free of actor concerns (in contrast to Vaughn Vernon who talks about turning domain aggregates into actors).

Would be lovely if you could shine a light, give some feedback on this setup as it relates to proto.actor..

[rogeralsing]

Hello @aschrijver

Absolutely, Inlining per question here:

Starting in reverse order:

How does Asynkron fit into the picture? What is your revenue model and relationship to proto.actor as an open-source project?

I'm the founder of Asynkron and the Proto.Actor project. Asynkron as a company is the owner of the Proto.Actor trademark. The opensource projects are also under a Contributors License Agreement, which grants Asynkron the signed license to use the contributed code.

Under Asynkron, we offer consulting services around scalability, distributed systems, workshops, training sessions around the actor model in general, and Proto.Actor as a framework, e.g. helping clients architect and implement Proto.Actor systems.

We are currently in negotiations with a potential partner company for setting up a full set of support plans for Proto.Actor. Offering developer support and full-fledged 24/7 SLA production support.

How are they related, i.e. kept in sync functionality / compatibility wise? Is Golang part of the long-term roadmap of proto.actor as something with prolonged commitment / support?

The plan is to keep the two fully in sync. currently working on porting over all the new cluster features from .NET to Go. Which project gets the most attention depends very much on where there currently are the most contributors, and what clients we are working with. e.g. I am working full time with a .NET customer right now, which leads to more progress on the .NET version.

Personally, I do believe Proto.Actor Go has a brighter future as Go generally is more used in the high-scalability world.

Hope this sheds some light on your questions?

Let me know if there is anything that I can elaborate on

[aschrijver]

Wow, thanks for the quick response (way quicker than expected, as I just cross-posted to the forum). I will move further discussion to this forum topic.

[rogeralsing]

I won't be using gRPC over the network (where I use AP), but was intending to use Hashicorp's go-plugin (which uses gRPC) to have a dynamic plugin system and ability to add/remove module extensions dynamically at runtime. I still need to check if/how this can be combined with proto.actor (Proto.Remote?).

This is an interesting topic, we are sketching on how to offer this out of the box. We have two similar but different in scope size approaches for this. The first is to allow for actor plugins, e.g. making it possible to hook the actor receive pipeline to a chain of external services. @alexeyzimarev is involved in this also. as the primary use-case is for our shared client project.

The other approach we have is to offer a Proto.Serverless module, which would build on a form of shapeless actors which only hold raw state in binary form, which then push this state and incoming messages to external services over gRPC. allowing actor logic to be written in any language. This is the same approach as Akka.Serverless and Dapr uses.

[aschrijver]

I will post the OT part to a new forum topic.. it has a bit too many links for a trust level 0 user, so I was posting some other stuff first :)

[rogeralsing]

Moved my replies there too. 👍🏻