@bimetal/sync
v0.37.0
Published
Sync primitives (v0.15). Framework-agnostic SyncTransport interface + InMemorySync loopback. Server-authority model, optimistic locking, no resolvers, no previous, no LWW.
Maintainers
Readme
@bimetal/sync
Sync-Primitive (v0.15) für BIMETAL. Ein strukturelles, framework-agnostisches
SyncTransport-Interface plus eine In-Memory-Loopback-Implementierung — die Grundlage für
Multi-Client-Synchronisation über eine Server-Autorität.
Das Modell ist bewusst schlank: Server-Autorität, Optimistic Locking, First-Writer-Wins. Keine
Resolver, kein previous-Feld, kein Last-Write-Wins, keine Timestamp-Tiebreaker, keine Merges im Kern —
ein Konflikt wird laut (ConcurrencyError), nicht still aufgelöst. Fachliche Merge-/Recovery-Strategien
gehören in die App, nicht ins Framework.
Installation
npm install @bimetal/sync @bimetal/event-sourcingWas das Paket liefert
| Export | Zweck |
|--------|-------|
| SyncTransport | Das strukturelle Transport-Interface (senden/empfangen von Sync-Nachrichten) — ein WebSocket-Adapter (@bimetal/sync-ws) implementiert es. |
| createSyncedEventStore(options) | Composer (kein Replacement): wickelt einen lokalen EventStore in einen sync-fähigen Store — lokale Appends gehen über den Transport an die Autorität, Remote-Events werden eingefoldet. Konfiguration über ein SyncedEventStoreOptions-Objekt. |
| createInMemorySync() / createInMemorySyncAuthority() | Loopback-Transport + In-Memory-Autorität — für Tests und Single-Prozess-Szenarien. |
| InMemorySyncAuthority | Der Autoritäts-Typ. |
Architektur
Cross-cutting (Transport). Konzepte: Event-Sourcing-Konzept und Backend-Überblick — dort auch „Wie groß wird das?“, die Grenze des Log-im-Client (Optimistic Locking / Concurrency).
