@bimetal/sync-ws
Der WebSocket-SyncTransport-Adapter für @bimetal/sync. Ein Browser-Client, der das
strukturelle SyncTransport-Interface über eine WebSocket-Verbindung implementiert — mit
Exponential-Backoff-Reconnect und transparenter Wiederherstellung der Subscriptions nach einem
Verbindungsabbruch.
Installation
npm install @bimetal/sync-ws @bimetal/sync
Was das Paket liefert
| Export | Zweck |
|---|---|
createWebSocketSync(options) | Erzeugt einen SyncTransport über eine WebSocket-URL: verbindet, reconnected mit Exponential-Backoff und re-installiert bestehende Subscriptions nach Reconnect transparent. Bei Protokollfehler bricht der Client sauber ab (Close 4002). |
WebSocketSyncOptions | Optionen (URL, Backoff, WebSocketFactory). url darf eine Funktion () => string | Promise<string> sein und die Factory ein Promise liefern (bimetal-304): beides wird bei jedem Verbindungsaufbau gerufen, auch beim Reconnect — so holt ein Konsument je Aufbau eine frische Eintrittskarte. Ein verworfenes Promise ist ein gescheiterter Aufbau (Backoff, neuer Versuch). |
subscribe(…, { onRejected }) | Verweigert die Autorität eine Subscription (subscribe-rejected, bimetal-304), endet sie endgültig: kein Frame an den Handler, keine Re-Installation nach einem Reconnect, die Verbindung bleibt stehen; onRejected bekommt Strom, Grund und Text. Hinter createSyncedEventStore steht dieselbe Ablehnung an SyncedEventStoreOptions.onRejected und als Zustand an rejectedStreams (bimetal-321) — caughtUp settelt auch für einen verweigerten Strom. |
transport.undo / .redo | Das Undo-Kommando an die Autorität (bimetal-259 S2) — derselbe Weg wie ein append (Request-Id, Antwort append-ok/append-rejected), der Promise settelt mit der Antwort. Die Methoden stehen auf dem Transport, sobald die Autorität sie im hello-Frame zugesagt hat (bimetal-292), sonst fehlen sie — der Konsument prüft auf Vorhandensein wie bei der In-Memory-Autorität. Eine Ablehnung mit Grund concurrency wird ein ConcurrencyError mit dem Text der Autorität (erwartete und vorgefundene Marke), jede andere ein schlichter Error. Die Semantik (was zurückgenommen wird, expectFrame) gehört zu @bimetal/sync (SyncTransport.undo), die Ausführung zur Autorität (@bimetal/server-sync mit undoDomain). |
WebSocketLike, WebSocketFactory | Einspeis-Punkte für Test-Doubles bzw. eine Node-ws-Implementierung. |
WS_READY_STATE | Die ReadyState-Konstanten. |
Die Gegenseite auf dem Server ist @bimetal/server-sync.
Catch-up in Frames (bimetal-372). Die Autorität schickt den Rückstand eines Stroms in events-Frames bis
maxFrameBytes (Vorgabe 1 MiB). Der Client dekodiert jeden Frame beim Eintreffen und wendet ihn je Subscription
der Reihe nach an; die Ströme eines Sockets laufen nebeneinander. Grenze: Wendet der lokale Store langsamer
an, als die Leitung liefert, wartet der Rückstand dekodiert im Speicher und wächst mit dem Strom. Einen
Rückmeldeweg an die Autorität gibt es nicht. Ein Eingang, der grosse Frames erst nach dem vorigen dekodierte,
brachte gemessen nichts und hielt viele Ströme hinter dem langsamsten auf (bimetal-373). Er ist entfernt.
Architektur
Cross-cutting (Client-Seite von sync). Tiefe: Event-Sourcing-Konzept und Backend-Überblick — dort auch „Wie groß wird das?“, die Grenze des Log-im-Client.