lavina/crates
Nikita Vilunov 26720a2a08 core: separate the model from the logic implementation (#66)
This separates the core in two layers – the model objects and the `LavinaCore` service. Service is responsible for implementing the application logic and exposing it as core's public API to projections, while the model objects will be independent of each other and responsible only for managing and owning in-memory data.

The model objects include:
1. `Storage` – the open connection to the SQLite DB.
2. `PlayerRegistry` – creates, stores refs to, and stops player actors.
3. `RoomRegistry` – manages active rooms.
4. `DialogRegistry` – manages active dialogs.
5. `Broadcasting` – manages subscriptions of players to rooms on remote cluster nodes.
6. `LavinaClient` – manages HTTP connections to remote cluster nodes.
7. `ClusterMetadata` – read-only configuration of the cluster metadata, i.e. allocation of entities to nodes.

As a result:
1. Model objects will be fully independent of each other, e.g. it's no longer necessary to provide a `Storage` to all registries, or to provide `PlayerRegistry` and `DialogRegistry` to each other.
2. Model objects will no longer be `Arc`-wrapped; instead the whole `Services` object will be `Arc`ed and provided to projections.
3. The public API of `lavina-core` will be properly delimited by the APIs of `LavinaCore`, `PlayerConnection` and so on.
4. `LavinaCore` and `PlayerConnection` will also contain APIs of all features, unlike it was previously with `RoomRegistry` and `DialogRegistry`. This is unfortunate, but it could be improved in future.

Reviewed-on: lavina/lavina#66
2024-05-13 14:32:45 +00:00
..
lavina-core core: separate the model from the logic implementation (#66) 2024-05-13 14:32:45 +00:00
mgmt-api management api endpoints for rooms 2024-05-01 17:30:31 +02:00
projection-irc core: separate the model from the logic implementation (#66) 2024-05-13 14:32:45 +00:00
projection-xmpp core: separate the model from the logic implementation (#66) 2024-05-13 14:32:45 +00:00
proto-irc irc: implement WHOIS command (#43) 2024-05-05 17:21:40 +00:00
proto-xmpp move repo methods into submodules and clean up warnings 2024-05-10 23:50:34 +02:00
sasl sasl: remove unused code 2024-04-23 00:41:54 +02:00
readme.md update docs 2023-10-10 02:30:50 +02:00

readme.md

Dependency diagram of the project

graph TD;
    lavina-->mgmt-api;
    lavina-->projection-irc;
    lavina-->projection-xmpp;
    lavina-->lavina-core;

    projection-irc-->proto-irc;
    projection-irc-->lavina-core;
    
    projection-xmpp-->proto-xmpp;
    projection-xmpp-->lavina-core;

    sim-irc-->proto-irc;
    sim-irc-->mgmt-api;

    sim-xmpp-->proto-xmpp;
    sim-xmpp-->mgmt-api;

    workspace-->lavina;
    workspace-->sim-irc;
    workspace-->sim-xmpp;

A few rules:

  • Only projections should be direct deps of lavina, there is no need to depend on proto-* crates.
  • On the other hand, projections should not be dependencies of sim-* crates.
  • lavina-core does not depend on protocol-specific crates.

Lavina

lavina-core. This crate implements the core functionality of the server not specific to public interfaces. It includes handling general persistence, message casts, in future room authorization and cross-node communication.

lavina. The application crate. It's used to link other crates together and build the final binary with support for all protocols.

mgmt-api. Model definitions for management API to be used both in the server and client implementations.

IRC

proto-irc. Protocol definition for IRC, includes both server-side and client-side messages and both serialization and deserialization where needed.

projection-irc. Projection of lavina-core onto the IRC client-to-server protocol implementation.

sim-irc. Future implementation of IRC client simulator to be used in integration and load testing.