[HN Gopher] Show HN: RemoteStorage - sync localStorage across de...
___________________________________________________________________
Show HN: RemoteStorage - sync localStorage across devices and
browsers
Hey HN! Wanted to share a new library and server I've recently been
working on called remoteStorage. When building frontends with
Javascript, the native localStorage API is super useful for keeping
track of state between sessions in the same browser, but it's not
as good a solution when your data needs to be shared across
multiple devices or browsers. For instance, let's say you want to
show a welcome modal to all new users that sign up for your
product. If you use localStorage to track if a user has already
seen this modal, your users will end up getting the experience
repeatedly every time they switch devices or browsers, or whenever
Chrome decides to nuke your data. I built remoteStorage to help
fix that. Using the same API as localStorage, remoteStorage allows
you to easily read and write data on the fly while maintaining
state across browsers and devices in order to provide a better user
experience. The project is built as a monorepo in Typescript and
contains a JS library that works across any Javascript stack
(including Node.js and React Native) and is lightweight (~1 kb
minified). The server is built with Nest.js with a disk-persisted
Redis Database. It can be deployed in a few minutes using Docker.
One of the biggest challenges when building this was coming up with
a secure scheme for handling authentication while still keeping the
API dead simple for frontend devs to use. While the project is
intended to store non-sensitive data like impression
events/preferences, I still wanted to make sure data couldn't
easily leak or be tampered with. One solution has been to generate
a unique secret UUID per user on your own backend to identify the
user. Alternatively, you could create a simple wrapper/proxy API
around remoteStorage that uses your own authentication method to
verify the user's identity before allowing them to access the data
(this is super simple to build with React Server Components). Then,
you could pick a secure and secret Instance ID that is not publicly
available to ensure that only your application can access the data.
Has anyone felt the same pain points with localStorage before? Is
this solution useful? Let me know what you think or ideas for how I
can improve it :)
Author : pancomplex
Score : 41 points
Date : 2024-01-12 19:01 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| thatwasunusual wrote:
| > let's say you want to show a welcome modal to all new users
| that sign up for your product.
|
| Not sure if this is a good example; how many users sign up for
| the same product multiple times?
| eddd-ddde wrote:
| They mean that on first login you should see the popup. If you
| used local storage, login in in a different device would
| wrongly consider it a first time login.
| pancomplex wrote:
| Yup, exactly. I'll update the readme to make this more clear.
| toomuchtodo wrote:
| Cookies or passkeys? Seems very complex when you can use
| something simply to track state and identity. Passkeys sync
| across cloud storage, for example, even if you're using a uuid as
| the username.
| cantSpellSober wrote:
| > while still keeping the API dead simple for frontend devs to
| use
|
| Selling point seems to be the API, I'd prefer an alternative to
| document.cookie.split(";"), a sane way to store objects, etc,
| frontend friendly.
|
| Typically use cookies to store data for the server (session id
| etc).
| pancomplex wrote:
| That's right -- my main idea with the library is to make it
| super simple for front end engineers to store
| preferences/flags server side without needing backend
| engineering work. Basically as simple as using localStorage
| itself :)
| vidarh wrote:
| The name Remotestorage is already used for a protocol for
| portable user-controlled storage. See e.g. Remotestorage.io.
| paulgb wrote:
| Your landing page at https://remote.storage/ is so good, I love
| the minimalism. Six lines of code tell me exactly what it does.
| SeanAnderson wrote:
| It's pretty good... but what if it showed a different landing
| page after visiting the website on a second machine? :)
| pancomplex wrote:
| Haha good call! Let's do it.
| SushiHippie wrote:
| Not to be confused with https://remotestorage.io/
| amadeuspagel wrote:
| How does this compare to PouchDB[1]?
|
| [1]: https://pouchdb.com/
| pancomplex wrote:
| I didn't actually know about PouchDB but it looks very useful!
|
| I think the main difference here is the use case. remoteStorage
| is not intended to be used as a database (just like
| localStorage is not intended to either), but rather to store
| non PII data such as preferences, impression events, etc.
| without having to roll and stand up your own DB and API.
| maxwellg wrote:
| On the authentication front - JWTs would be a great fit here!
|
| The developer's backend could issue a JWT, which is validated by
| the remoteStorage backend. Then, use the `sub` field as the user
| ID. JWTs are pretty ubiquitous in frontend applications, so many
| people would be able to reuse their existing auth setup.
| pancomplex wrote:
| Love this idea. Especially because JWTs are so ubiquitous like
| you mentioned, this could be a very lightweight way to secure
| the calls without doing too much if any backend work. My main
| goal is to make it as easy to use as localStorage itself but
| with all the benefits and security of having a centralized
| state/store.
| shunyaekam wrote:
| What is special with the server? I was surprised you offered a
| community-hosted server.
|
| An OpenAPI spec should be enough, right?
| pancomplex wrote:
| Yes, I'll get an OpenAPI spec rolling soon. You can easily
| infer the API here for now:
| https://github.com/FrigadeHQ/remote-storage/blob/main/packag...
|
| The server is nothing special by design, just essentially
| Docker/Node/Redis with persistence enabled.
|
| The free hosted community server is supposed to be used for
| testing / proof of concept.
| lxe wrote:
| So, just a UUID to authenticate? How do you recover/reset in case
| it gets lost?
| pancomplex wrote:
| You'd need to keep track of that somewhere for now, but as
| someone else suggested here, we could soon extend the library
| to support JWTs for authentication.
| matlin wrote:
| I love the simplicity and kinda wish that was actually built into
| Chrome.
|
| I know it would probably break things but if Google could
| automatically sync local storage and IndexedDB when I'm signed
| into Chrome on all my devices then a lot browser of apps wouldn't
| require making an account or even a server for that matter.
| pancomplex wrote:
| Thank you! My goal was to make it as stupidly simple as
| possible in the first version.
|
| I am also pretty surprised Google hasn't yet built something
| that solves this. When localStorage first came out, I was
| expecting a natural extension would be a way to sync it to a
| centralized store to avoid having state reset between
| sessions/devices.
| simlevesque wrote:
| That's so cool ! I was thinking how I'd make work syncing my
| offline first app and this looks promising
| matlin wrote:
| Your app might not need it but if you want partial replication
| or relational querying in addition to offline-first syncing
| then check out https://github.com/aspen-cloud/triplit
| (disclaimer: I'm working on this)
| internetter wrote:
| how does this compare to https://electric-sql.com/
| pancomplex wrote:
| That's a super valid use case. Let me know how it goes!
| ocdtrekkie wrote:
| > Has anyone felt the same pain points with localStorage before?
|
| For Sandstorm, we've always want to make sure app data is stored
| on a server, but an increasing number of web apps love to use
| localStorage as a cheap hack to avoid writing a backend. I recall
| a bunch of attempts back in the day, but we were always looking
| for a simple way to include something with an app written to use
| localStorage which could store the data on a server backend
| instead.
___________________________________________________________________
(page generated 2024-01-12 23:00 UTC)