Proto Eventuous integration

[rogeralsing]

In the best of worlds, I'd like to obsolete the Proto.Persistence libs and instead have a proper adapter for a library like this. This would both benefit the ecosystem to have a more generic lib like this where everyone focuses on the persistence efforts. and be in the spirit of ProtoActor to leverage already existing tools.

• Pluggable serialization
• Semaphore limits on reads / writes, e.g. prevent more than X concurrent reads/writes at any given point in time. e.g. big actor systems booting up can easily kill a database if no such feature is in place
• Batch reads and writes across aggregates. similar to the above, but many actors asks to read or write state, all of these actions are collected in a single aggregator and leveraging DB level features for batch operations

[alexeyzimarev]

The question is from which side this to be approached.

• The current proto persistence has nice features like snapshot strategies. I have not implemented snapshotting yet, but if I do, it might not support strategies other than event count.
• I currently only plan to support ESDB adapters as this is an application-oriented library, with a focus on apps with proper domain models. Therefore, I need subscriptions. The IEventStore interface is trivial to implement for other databases, but I don't see how it fits the library.
• I want to have Proto.Actor integration from the application side. For example, implement an application service as an actor.

I agree that handling backpressure on the database properly is a good feature to build anyway, as even a normal system might struggle under peak load.

[alexeyzimarev]

Maybe I haven't made my point clear enough... Eventuous is not a tech lib for shovelling events to the store, it's a library to build business apps with tactical DDD, Event Sourcing and CQRS. We can discuss if the case of Proto.Persistence alone can fit here, and how.

Still, my plan to use Proto.Actor from the application side is very real.