davidbm / acteur-rs

An safe & opinionated actor-like framework written in Rust that just works. Simple, robust, fast, documented.

Hi there 👋

Welcome! It's cool that you are here.

Feel free to check whatever you like. Lately I'm working mostly with Rust in the FinTech sector and open source space.

Open source

If you are looking at any of my projects and have any question, feel free to open an issue.

My main open source projects:

• [RUST] https://github.com/DavidBM/qldb-rs - Driver for the AWS QLDB Ledger/Database
• [RUST] https://github.com/DavidBM/ion-binary-rs - Implementation of Amazon Ion format (a BSON-like format, but better)
• [RUST] https://github.com/DavidBM/acteur-rs (an opinionated actors' framework)
• [RUST] https://github.com/DavidBM/rsmq-async-rs (RSMQ queue system implementation in Rust)
• [JS] https://github.com/endangeredlanguagesproject/COVID-19/ (donated code for COVID-19 info in endangered languages)
• And other old projects in TypeScript, and even older in JavaScript, that you can find in my repos.

Although lately I'm not having too much time with work and my daughter. So contributions are welcome!

Enjoy the code! 😄

Me

Personally I work with Rust as my main language, but I'm fully versed in Javascript and Typescript too. I'm familiar with Python, Go, Ruby, C and C++, etc.

I'm fully competent using Linux, MySQL, Redis, ElasticSearch, Eventstore, Docker, Google Cloud, Amazon AWS, Serverless (mostly AWS Lambda), HTML5, DOM, WebWorkers, CSS, etc. I like doing low level stuff like the binary parser/encoder for Ion and the QLDB Database driver.

I've worked occasionally with Kubernetes, WebGL, Vuej.js, React.js, Cordova, and many others that aren't coming to my mind right now. I've used niche FinTech things like ISO 20022, ASN.1, PSD2, etc.

I did some video game development in the browser and in C++. Hopefully I will be able to continue with it in the future. I worked a bit with USB under Linux, done some web scrapping and toyed with ECS a bit too. In my free time I'm with my family and when I have time, I do some open source code too.

I have been software developer, architect, team lead, CTO and CEO in the last 14 years, but I enjoy coding full time now.

acteur-rs's Issues

Singleton services

Is your feature request related to a problem? Please describe.
I have a service that manages the configuration data for my application. This configuration data is loaded from a file when the service is created, and is saved whenever a value is changed. These changes can be sent to the service from any other service/actor, but only one instance of the ConfigService should ever exist because it holds a handle to the config file and multiple instances would override each others' changes and potentially lose config data.

I've used ServiceConcurrency::None to have only a single instance of the service, but it still requires that the data is wrapped in a Mutex. It's possible to make a singleton this way, but not very convenient/user-friendly for something where I should be able to assume concurrent access will not happen (because messages are processed one by one).

Describe the solution you'd like
A Singleton trait, similar to Service, that guarantees only a single instance of the service exists, that doesn't require me to use a Mutex for its state, and that uses &mut self for its Listen & Serve traits.

Example (pseudocode):

struct ConfigService {
    file_handle: File,
}

impl Singleton for ConfigService {
    async fn initialize(system) -> Self {
        ConfigService {
            file: File::Open().await,
        }
    }
}

struct SetConfig(String);

impl Listen<SetConfig> for ConfigService {
    async fn handle(&mut self, data: SetConfig) {
        self.file.write_all(data.0).await;
    }
}

How to handle failures during Actor activation / Service initialization

Is it best to panic and let Acteur deal with the problem? For example, I want to setup a database connection in a service, which might fail. Obviously, that would be a fatal error and I would abort anyway. Just curious about the best practices.

Open question about goint the cluster mode

So, the idea is to have a cluster where each node is able have a chunk of the actors.
If, for example, there are 100.000 actors and 5 instances in the cluster, then there should be 20.000 actors in each server.

Things I need to think (and where help is very welcomed):

• What happens if a server crashes? Should we replicate the enqueued messages in order to not lose messages?
• Raft? I'm checking it and it seems good.
• Should the consensus algorithm sync messages or just where is each actor?
• Until what point should the actor inboxes being persistent?
• Is it worth it to have a cluster where if any instance dies are messages lost?

Many decisions!

Timed interval/tick?

What is the best way to implement a 'tick' in some actors?

I'm playing around with Acteur for the backend for a multiplayer game. A lot of the actors only need to respond when a player interacts with it, so a full ECS that runs everything constantly would be overkill. But there are a set of actors that do need to be updated every tick (e.g. 20 times per second). Think of a Minecraft world where a lot of things just "stand around" (like doors and tables and torches) but there are also animals and mobs that need to move on each game tick.

Does Acteur have a built-in feature to call a function on an actor in a timed interval, or what would be the advised way to handle this? Should I just keep a timer outside of Acteur and send a 'tick' message to the actors every time?