protoactor-dotnet
protoactor-dotnet copied to clipboard
asynkron
:raised_hands: Community feedback needed :raised_hands: Roadmap planning
We are focusing our efforts on stability around the project and the API so we would like to adjust how new features are developed and to add more planning regarding introducing new features in the next coming releases.
The idea is to create a plan for one, two next releases OR for some fixed period of time, e.g. month or two. It all may depend on community engagement. The roadmap plan should contain a list of issues/features that are going to be released in the next versions.
To prepare such a plan it is needed to get as much feedback from the community and the existing Proto.Actor users as possible. Such a list might be prioritized then and put into our roadmap plan.
If you need some features in Proto.Actor or any enhancement or you see places that might improve it please add it in this issue.
Hey @seungyongshim I assume by MySQL persistence you mean the event-sourced implementation? Can you explain what your use case for event sourcing with actors is? Could it be replaced with simply storing actor state as-is in the database?
Regarding persistence, we should aim to replace the SQL based providers with an abstraction using https://linq2db.github.io/ Which allows a unified way of interacting with most relational DBs out there
- Increase API coverage of documentation
- Include intellisense documentation or source link in nuget package
@wldevries SourceLink is included since a couple of years back https://github.com/asynkron/protoactor-dotnet/blob/51bbe10c81ab26d12f6a78aee18695ea0315af33/src/Directory.Build.props#L22
👍 mistake on my side. I expected the "Go to definition" feature in Visual Studio to use Source Link. Unfortunately it does not.
https://github.com/dotnet/roslyn/issues/24349
@marcinbudny Grain persistence case
- https://dotnet.github.io/orleans/docs/grains/grain_persistence/index.html
- https://v1-7.docs.dapr.io/developing-applications/building-blocks/actors/howto-actors/#actor-state-management
Could MagicOnion and MsgPack be a possibility? Mainly MessagePack, since it is faster serialization than protobuf, could increase more messages per second.
@juliolitwin We are using MessagePack together with Proto.Actor for quite a while, it works really well. We wrote a serializer, and instead of using typename, we use integer ids for each type we define. This allows multiple versions of the app to work together even after refactoring class names. Default protobuf serializer of Proto.Remote uses class name as the identifier, so it wouldn't support renaming structs. However, MessagePack is slower than protobuf generator (if I remember correctly, it was about 30% slower when I benchmarked it a long time ago). On MessagePack repo, it states that it is faster than protobuf-net, which is a reflection-based protobuf serialization library, very different than what Proto.Remote uses.
If you are interested, we can open-source our MessagePack serializer. We added some nice things on top, such as:
- Being able to serialize certain structs via NeftonsoftJson, or System.Text.Json
- Automatically serializing Protobuf structs
- Automatically serializing Apache Thrift structs
- Serializing PID and ClusterIdentity types.
- A much better reviewed+tested Proto.Cluster and Proto.Remote libs. I have been having issues with it for quite a while, unfortunately, when there are issues, there is very little I can do to get any meaningful data to diagnose the issue. Maybe a function like "string DumpInternalState()" could be nice, if it would dump all internal cluster/partitionIdentity states. That would at least allow us to create a Github issue with that data. Maybe that data could include historical changes too? Later, https://github.com/asynkron/protoactor-cluster-dashboard would be amazing, especially if it was made in a way that we can embed it into our process, rather than using it as a separate app.
- Documentation on all public APIs. This is severely lacking. Code has little to no comments. Ideally, I would like to see a lot more internal comments in the critical and complicated sections of the code.
- Meaningful commit messages. I assume using empty commit messages in work branches should be fine, but before merging, it would be great to rebase, and squash those together.
Collecting community feedback to determine the roadmap is super great! Big thanks to all the contributors of the project!
- UnderlyingActor for Unittest
- https://getakka.net/articles/actors/testing-actor-systems.html#obtaining-a-reference-to-an-actor
@DenizPiri
It will be awesome if you can opensrc MsgPack extensions, and thanks for sharing the information with us! :]
Now a question, I was worried when you said that you are having problems with Proto.Cluster and Proto.Remote. In your opinion and experiences, do you think the ProtoActor is not ready for production yet?
Anyway, thanks to the whole team @rogeralsing for being so active on the project, and I'm looking forward to the dashboard project. :)
I am very curious to know if anyone is already using ProActor in production and especially for GameServer.
Cheers!
@juliolitwin Just done: https://github.com/AhoyGames/Ahoy.Proto.MessagePack Published it to nuget too. https://www.nuget.org/packages/Ahoy.Proto.MessagePack/ I will try to maintain it and make sure it follows the new Proto.Actor releases. Ahoy.MessagePack.NewtonsoftJson, Ahoy.MessagePack.Protobuf, Ahoy.MessagePack.Thrift and Ahoy.MessagePack.SystemJson can be used without any Proto.Actor dependency.
As for Proto.Cluster and Remote. I believe Remote is very solid, had no issues with it so far. In terms of Proto.Cluster, had many issues before 0.27, at 0.27 it seems pretty solid so far. Only had one strange actor imbalance issue few days ago. Outside of that, no issues to speak of. However, overall I believe it would help the project a lot if those 2 projects and of course the core Proto.Actor lib would be a lot better tested overall.
We do use Actors for games in our game servers, but not Proto.Actor, our own in-process implementation. However, we recently started utilizing Proto.Actor for main services such as matchmaking, etc... We also utilize Proto.Actor for all network communication with game clients in each of our projects for quite a while.
Also big thanks from me to @rogeralsing, @mhelleborg, and all the other contributors. Looking forward to seeing how this project evolves and looking forward to utilizing it more and more! I believe there is a big potential! 💯
Please create samples of simple systems (Hello World) that actually ready to work in Cloud with clustering not on local developer machine.
For .Net it is ASP Net Core Generic Host version sample that work alongside ASP itself and can work on Cloud infrastructure of few main Cloud Providers with at least 2 cluster nodes communicating:
- Microsoft Azure
- Google App Engine
- Amazon AWS
It is really hard to make clustering work on real production environment (not on local production sandbox)
Actually few months trying to make clustering work on Google App Engine with no luck. Nodes just can not see each other.
I believe it is not rare for developers to try move from pure ASP Net Core to Actor model on already working servers in some environment.
I'd like to see more error details in the terminated message #535 to avoid duplication in code for error management.
I would second the need for "A much better reviewed+tested Proto.Cluster and Proto.Remote libs". It's happened several times that after an upgrade to the latest version of proto.actor I have to spend a fair bit of time working out why things are working differently. Expected in a pre 1.0 solution, but long term this needs to be addressed.
- Increase the API coverage of documentation.
- Provide more sample applications.
- Add MemoryPack support.
- Mocking grain client and testability https://github.com/asynkron/protoactor-dotnet/issues/2019
- Actors debug experience improvements
