remoteStorage

Multiple storage accounts as a proxy for syncing over the local network

#1

I tried an experiment as a way to approximate syncing between devices over the local network (for when you don’t have internet access). I thought that if you could run a remoteStorage server from localhost and then make it accessible via wifi, you could temporarily swap out the tokens in the app and sync locally, and then when you have internet access you could swap the tokens back to propagate the changes to the cloud server.

As a way to simulate this quickly I used a second 5apps account. I created some objects in my app and then after they synced to another device, I swapped my username and token with that of the second account. Well I guess I have no idea how the library works because it just removed the objects from local storage instead of trying to sync them to the second account; I thought it would see that there are objects not currently on the server and then add them to the new account. Can anyone summarize how this is implemented? Would it be naive to try and make this possibiltty work for real?

#2

You can inspect your local remoteStorage (IndexedDB) database to get a better idea of how this works

You will find that the library keeps track of which items have been synced already by storing them in different keys/properties, depending on sync/caching status (local vs. common vs. remote). And thus, if it sees the remote not having an item anymore, it considers it as having been deleted from the remote. Which will also delete it from the local database.

I think this is the part of the sync where that happens:

(The return value there is used by other code to update the cache.)

1 Like
#3

Unfortunately, the Sync module is the least straight-forward one in the entire library at the moment (in my opinion). I have a branch lying around on my machine that switches everything to TypeScript, so that it’s easier to make sense of all the values being passed around, which I did so I could start refactoring it in the first place.

I didn’t get to the types yet, because it was a bit of an effort to convert everything to modern classes first. Just pushed the branch, in case anyone is interested in helping with this.

#4

Just a question: why don’t you just go offline in one browser, but stay online in another one (via dev tools)? Different browsers are essentially the same thing as different devices for the library, so your experiment seems like quite the overkill to me for testing sync behavior. Maybe I’m missing something?

#5

That explains why the existing items disappear instead of transferring to the new account. I guess I would need to modify it so that when the account changes it overwrites everything with the state of the local version instead of trying to merge.

#6

Well I said device but I meant browser, I actually used private and non-private windows. I don’t understand the ‘offline’ part because it needs to be online in order to sync right?

#7

Trying to think of a way to do this without touching the server code, only modifying remotestorage.js. I think it’s just a matter of creating a function that clears all writeable data on the server and pushes client copies up:

  1. Server A is in the cloud and synchronized with Client 1 and 2
  2. Server B is on the local network in an unknown state
  3. Client 1 switches to Server B and chooses to clear any writeable data on the server and replace with the client copies
  4. Client 2 switches to Server B and chooses to syncronize as normal
  5. Client 1 and 2 should now be synchronized with Server B and can send changes across the local network