Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: RemoteStorage – sync localStorage across devices and browsers

github.com

Post reply on HN
Print view View original

31–40 of 69 posts

Re: Show HN: RemoteStorage – sync localStorage across devices and browsers

#32

Post by joshstrange »

pancomplex wrote: post #30
joshstrange wrote: post #29

Very cool overall but the sync->async change means you can't always use it as a drop-in replacement. I assume it's making network calls in those cases which will take significantly longer that local writes. I wonder if something could be done so that it write the data locally and kicks off something async in the background to sync it up to the backend. Maybe with just a timestamp in case you go offline to handle conf…

Good question. I like the idea of having a configuration that includes optimistic writes and perhaps even reads from localStorage for projects that have very low latency/unstable network requirements. That being said, the server is blazingly fast as it leverages Redis and Fastify under the hood. In most of my testing, even on WiFi in SF with a server in Oregon, I would achieve <20ms reads/writes.

Totally fair point and I understand that as-is it’s way simpler than what I proposed. I just know there are places I have to change a whole chain of functions from sync to async to use this (not the end of the world).

I’m tempted to rewrite the backend in lambda+dynamoDB for a completely serverless backend (though for anything serious you’d probably want provisioned lambdas to avoid the cold start).

Re: Show HN: RemoteStorage – sync localStorage across devices and browsers

#33

Post by pancomplex »

joshstrange wrote: post #32
pancomplex wrote: post #30

Earlier quoted context omitted.

Good question. I like the idea of having a configuration that includes optimistic writes and perhaps even reads from localStorage for projects that have very low latency/unstable network requirements. That being said, the server is blazingly fast as it leverages Redis and Fastify under the hood. In most of my testing, even on WiFi in SF with a server in Oregon, I would achieve <20ms reads/writes.

Totally fair point and I understand that as-is it’s way simpler than what I proposed. I just know there are places I have to change a whole chain of functions from sync to async to use this (not the end of the world). I’m tempted to rewrite the backend in lambda+dynamoDB for a completely serverless backend (though for anything serious you’d probably want provisioned lambdas to avoid the cold start).

That sounds super useful. If you follow through with it feel free to open a PR with either code or a link to an AWS recipe.

Ideally we have as many different server and client implementations as possible in the monorepo.

Re: Show HN: RemoteStorage – sync localStorage across devices and browsers

#35

Post by pancomplex »

thih9 wrote: post #34

Can this be treated as tracking or storing information about the user in the context of data regulations (like gdpr and similar)?

Depends on what kind of data you are storing? The good news is you can self-host, so it's trivial to spin up a server in your own datacenter that meets your compliance requirements.

Re: Show HN: RemoteStorage – sync localStorage across devices and browsers

#37

Post by NegativeLatency »

eps wrote: post #36

How are the conflicts resolved? Machine A is online and sets "x" to 1. Machine B is offline and sets "x" to 2. Machine B goes online. What the resulting state on A and on B? What if initially A was offline and B was online?

Since B is offline it never sets x to 2: https://github.com/FrigadeHQ/remote-storage/blob/main/packag...

Re: Show HN: RemoteStorage – sync localStorage across devices and browsers

#38

Post by pancomplex »

eps wrote: post #36

How are the conflicts resolved? Machine A is online and sets "x" to 1. Machine B is offline and sets "x" to 2. Machine B goes online. What the resulting state on A and on B? What if initially A was offline and B was online?

This is handled by Redis, as such, the last write will win. As the primary key is tied to the user id, there will not really be a concept of Machine A vs Machine B as the end user can only be in one place at a time.
Post reply on HN