It's a server authoritative system, so the final state is determined by the server. There's a single global order of changes (basically the order the changes were processed by the server), so any conflicts are basically resolved by the server, but are applied optimistically on the clients when online or offline.
I can't tell exactly from your question if you're asking about the client going offline before or after making the change, or before or after recieving the server's version of the change, but either way the servers version wins and the client will have to catch up after it's back online.
You nailed it! In SQLSync, conflict handling happens in a WebAssembly module provided by the developer (for now). This module is free to handle conflicts in any way you see fit. You could even embed CRDT state into a table cell if you wanted to do rich collaborative text editing for example. My goal is to solve replication/durability and leave the specifics of conflicts up to the developer.
I was confused at first because I saw nothing in the Network tab of the browser dev tools.
But I figured it out; opening the dev tools for the shared worker, one can see that it does a websocket connection upgrade when the page is reloaded.
The github reads "designed to synchronize web application state". But, what if I also have e.g. an Android app and would like to synchronize state with it also? Is that out of scope or something considered for the future?
Glad you figured it out! I wish shared worker debugging was more obvious tbh, but oh well.
Yes, that's in the roadmap and will be much easier to do once I release the new storage engine I'm building. It's going to be a native vanilla SQLite extension which will be trivial to integrate into any environment that can already run SQLite (assuming the env allows extensions).
SQLSync does not use CRDT's to handle conflicts. Rather it uses a rebase approach. The developer provides a small Wasm module which implements transactions and can handle conflicts. This module runs on both the client and the server to run transactions. Clients periodically rebase on top of the latest server state, while re-running any unapplied transactions.
10 comments
[ 2.8 ms ] story [ 34.3 ms ] threadI can't tell exactly from your question if you're asking about the client going offline before or after making the change, or before or after recieving the server's version of the change, but either way the servers version wins and the client will have to catch up after it's back online.
But I figured it out; opening the dev tools for the shared worker, one can see that it does a websocket connection upgrade when the page is reloaded.
The github reads "designed to synchronize web application state". But, what if I also have e.g. an Android app and would like to synchronize state with it also? Is that out of scope or something considered for the future?
Edit: This issue seems promising: https://github.com/orbitinghail/sqlsync/issues/46
Yes, that's in the roadmap and will be much easier to do once I release the new storage engine I'm building. It's going to be a native vanilla SQLite extension which will be trivial to integrate into any environment that can already run SQLite (assuming the env allows extensions).