6 releases

0.2.2 Sep 18, 2022
0.2.0 Aug 21, 2022
0.1.4 May 21, 2022
0.1.3 Nov 17, 2021
0.0.1 Feb 17, 2021

#17 in WebSocket

Download history 15/week @ 2022-12-03 24/week @ 2022-12-10 34/week @ 2022-12-17 20/week @ 2022-12-24 64/week @ 2022-12-31 20/week @ 2023-01-07 20/week @ 2023-01-14 28/week @ 2023-01-21 45/week @ 2023-01-28 45/week @ 2023-02-04 38/week @ 2023-02-11 56/week @ 2023-02-18 17/week @ 2023-02-25 12/week @ 2023-03-04 11/week @ 2023-03-11 65/week @ 2023-03-18

108 downloads per month

MIT license



GitHub Repo stars crates.io docs.rs wokflow state

Cartoonized face of an ape.

Aper is a Rust library for data synchronization using state machines. Aper provides mechanisms to represent common data structures in terms of state machines, as well as a transport-agnostic protocol for keeping multiple instances of a state machine synchronized across a network.

Use-cases include real-time multiplayer applications that operate on shared state, client-server applications that want to share state updates incrementally and bidirectionally, and multiplayer turn-based games.

What is a state machine?

For the purposes of Aper, a state machine is simply a struct or enum that implements StateMachine and has the following properties:

  • It defines a StateMachine::Transition type, through which every possible change to the state can be described. It is usually useful, though not required, that this be an enum type.
  • It defines a StateMachine::Conflict type, which describes a conflict which may occur when a transition is applied that is not valid at the time it is applied. For simple types where a conflict is impossible, you can use NeverConflict for this.
  • All state updates are deterministic: if you clone a StateMachine and a Transition, the result of applying the cloned transition to the cloned state must be identical to applying the original transition to the original state.

Here's an example StateMachine implementing a counter:

use aper::{StateMachine, NeverConflict};
use serde::{Serialize, Deserialize};

#[derive(Serialize, Deserialize, Clone, Debug, Default)]
struct Counter { value: i64 }

#[derive(Serialize, Deserialize, Clone, Debug, PartialEq)]
enum CounterTransition {

impl StateMachine for Counter {
    type Transition = CounterTransition;
    type Conflict = NeverConflict;

    fn apply(&self, event: &CounterTransition) -> Result<Counter, NeverConflict> {
        match event {
            CounterTransition::Reset => Ok(Counter {value: 0}),
            CounterTransition::Increment(amount) => Ok(Counter {value: self.value + amount}),
            CounterTransition::Decrement(amount) => Ok(Counter {value: self.value - amount}),

Why not CRDT?

Conflict-free replicated data types are a really neat way of representing data that's shared between peers. In order to avoid the need for a central “source of truth”, CRDTs require that update operations (i.e. state transitions) be commutative. This allows them to represent a bunch of common data structures, but doesn't allow you to represent arbitrarily complex update logic. By relying on a central authority, a state-machine approach allows you to implement data structures with arbitrary update logic, such as atomic moves of a value between two data structures, or the rules of a board game.

Aper is rapidly evolving. Consider this a technology preview. See the list of issues outstanding for version 1.0


~71K SLoC