The README.me has an issue. It points to https://badge.socket.dev/npm/package/@nerdalytics/beacon/latest which doesn't exist. It should be a specific version such as 1000.2.3
Interesting, but only part of a solution. Aside: what's up with that version number?
I've given a lot of thought to needs that this would fit, and I've mostly considered the use of Redux, or something closer to it. The other part of the issue is what to do with that data, this is where you will likely either be replicating state changes/diffs across something like websocket channels or you will wrap that into something like Apollo for GraphQL updates similarly.
In any case, this really feels like only a small part of what you might need for a solution, and really need to consider how this fits and if it really suits the needs of an application/solution whole.
Beacon is backend-focused state primitives—metrics, config, service state. Not trying to replace Redux/Apollo.
You're right that transport/sync is the missing piece. That's on the roadmap as Beacon-Transport, but nothing publishable yet.
The plan: WebSockets with value diffing (not action/patch history). Last-write-wins. The advantage: recovering state is a single read instead of replaying patches—faster failure recovery.
Current ecosystem status:
Beacon (1000.2.3): Core reactivity—complete for my backend needs
Beacon-Durable (next release): SQLite-backed persistence, resumability
Beacon-Rules (following): FSM foundation
Beacon-Transport (future): Client sync over WebSockets
That's cool... and I literally meant Redux as a state machine on the server, have considered doing this for shared state app, and then sending JSON diffs to the client via WS, then client events likewise bubble to server as a round trip.
This would be for a shared learning environment/simulation... though could probably work for a game where some level of lag is tolerable. Such as a shared board or card game, etc.
I applied the concept of Epoch SemVer https://antfu.me/posts/epoch-semver
Without actually using it, I can't have an informed opinion about it.
I disagree with SemVer that security fixes are just patch bumps. Some security updates require a breaking change, requiring the major version to bump. Epoch SemVer supports that.
Bumping the version 1000.2.3 → 1001.0.0 could signal a security fix with behavior changes in backwards-incompatible way.