Module app

Module app 

Source
Expand description

The application: one merge point, one sequencer, one durable fold, N per-session views.

 sockets ──▶ ingress channel ──▶ [ validate ─▶ append ─▶ fold ] ──▶ version watch ──▶ diff per subscriber
            (merge_clients:            the single writer;              coalescing:
             the one place time         seq assigned once              a slow client gets
             enters, §3.7)              (§3.7)                         fewer, bigger patches)

Phase 0 wrote this by hand to find out what it costs; Phase 1 keeps the shape — docs/18 §18.7 item 1: “Keep the sequencer shape. One merge point, one writer, group commit, fold under the same lock as the append. It is simple, it is fast enough, and every property in §18.3.6 depends on it” — and drives it from a compiled program instead of from hand-written Rust.

What changed: validate, apply_event and view are now Core the splitter handed over, prepared by whichever [beck_core::backend::Backend] the process chose. Everything else — the batching, the ordering, the ack-versus-frame protocol rule Phase 0 learned the hard way — is unchanged, because it was never domain-specific.

Structs§

App
AppConfig

Functions§

replay_from_genesis
Fold the whole log from genesis, ignoring snapshots.
replay_to
Fold the log from the best available starting point — a snapshot if there is one, genesis otherwise. This is beck replay, and the resumption path uses it to reconstruct the view a reconnecting subscriber last saw.