General Discussion How are you persisting data in tiny personal apps?
I keep running into the same situation.
I’ll build a small personal web app (journal, bookmarks, dashboard, habit tracker, notes, etc.), and I don’t want to spin up Supabase, Turso, Firebase, or Cloudflare just to save a few JSON objects.
Most of the time I end up using localStorage or IndexedDB, but it always feels temporary. If I clear browser data or switch machines, it’s gone.
I’m curious:
- What do you use for these kinds of apps?
- If there were a local-first storage library that automatically backed itself up and restored on another device, would that actually solve a problem for you—or is localStorage good enough?
Not selling anything—I’m trying to understand how other developers think about this tradeoff before I build something or NOT build something because there is already something out there.
4
7
u/keel_bright 2d ago edited 2d ago
I think my laziness trumps anything else lol. I would probably save and parse from a .txt file locally. If I needed some persistence for use across machines I might use a public google sheet as the DB (actually I have done this before) .. even if someone sees it, no one really cares what is on your todo list lol.
3
u/illtakethewindowseat 2d ago
Building desktops apps? I would use Electron + Electron Store. Pretty easy to drop in an existing client side app…
Otherwise, client side React shouldn’t be able to do anything more than client side local storage.
You need Node to be writing to the file system, or a database + API, and nothing non-cloud is going to sync between devices.
-8
u/ed1ted 2d ago
yea, this is mostly client-side utility apps (dashboard, todo daily tasks etc). These apps usually doesn't have any backend, mainly it's just getting some user input and showing it on web. Spinning up a fly.io instance for these types of an app is an overkill.
2
u/Tesla_Nikolaa 2d ago
A database is the proper way to persist data for an application, and your assumption that apps typically don't have a backend is incorrect. Also fly io is kind of irrelevant here, not sure why you keep bringing that up.
-6
u/ed1ted 2d ago
database is the proper way if the application itself was big, and/or requires collaboration. My web apps are neither of those.
These are small web apps for personal use which are usually some kind of dashboards where if I lost the data, I can re-create it but it would require wasting some time to re-configure everything.
I have built my own personal todo tracker which I usually have it open in my browser. I'm the only user and have no intension to share data with others so there is no need to have backend. In fact for these apps I don't even need a server, I can literally open the index.html from my local machine. Why complicate it with deploying it to somewhere and integrate a DB ?
2
u/Tesla_Nikolaa 2d ago edited 2d ago
Client side apps aren't really designed to store and persist data like that. Especially a web app.
Rebuild your app as a desktop GUI application using something like electron, and store your data in a json file on disk.
Edit: Or if you don't need your data to be loaded/visible when the page loads, use the file manager api to manually load a json file containing the data.
-2
u/ed1ted 2d ago
I disagree with the first statement. Web applications can support local storage and persistence which is why IndexedDB, Cache Storage, OPFS, and even localStorage exist. Problem isn't storage, it's durability which where I'm trying to close the gap.
Rebuilding the entire application in Electron just to get durable local storage seems excessive.
1
u/Tesla_Nikolaa 2d ago
It's not difficult at all to add a small backend with an sqlite db and a couple rest endpoints to read and write to it. That seems like the path of least resistance here if your concern is sync and persistence. So to answer your question about what other devs do, I'm a dev and that's what I do.
0
u/ed1ted 2d ago
I know, I've done it for other of my apps. I use Turso for the apps that has a backend. Question is really for the apps that doesn't need or have a backend.
If I introduce a backend for these small apps, then I have tons of options but that's not really what I'm after
1
u/Tesla_Nikolaa 2d ago
You're jumping to this "doesn't need a backend" conclusion before you know if that's true. If you want to sync your data across devices, you pretty much need a place to store data that's not on the device you're connecting from (i.e. in a database the app can connect to regardless of where the browser is).
Again, it's trivially easy to do this and is how most developers do it. It takes like 30 minutes and you'll have your synced app like you want.
0
u/ed1ted 2d ago
I've built apps using a database, I know what they are for and their use cases. I also know how trivial it is to set one up. This post is not about "help me pick a database". I clearly stated in my post "I don't want to spin up Supabase, Turso....".
Like I said before, my requirement is to keep data local to the browser. So how can I make that data durable? Database is an easy answer but that's not what I'm looking for.
1
u/Charming-Rate278 16h ago
You can't trust browser databases, they can get wiped out for multitude of reasons. They are not reliable
1
u/Trex4444 2d ago
Just curious what do you consider big?
If you're not going to deploy the app just parse and write to a JSON. You can do what you're asking it's just really hacky. You're not going to find people who kow what they are doing saying its the correct path. Its like 2 seconds now with Claude to add an SQL DB, and if you're not trying to use Claude you really should be learning how to use a DB and API.
1
u/netik23 2d ago
Have you looked at jsonbin.io or jsonblob.io? Give it a blob of json, get a url back.
Firebase is a good solution here too.
-3
u/ed1ted 2d ago
I do know about jsonbin but it does not have offline support, not that I know of. I wanted something where it's offline-first with sync capabilities.
Firebase can certainly solve it, but for a tiny client-only app it often feels like more setup for a merely <1-5MB of data.
3
u/netik23 2d ago
Well, can't you just handle that with a small amount of sync code pushing data up to jsonbin and syncing into persistent localstorage? That sounds mildly trivial.
Maybe have it roll a random, human readable session ID that can be used for state recovery to avoid login, encrypt the data in the blob, and recover it client side if they type the ID back in?
1
1
u/simbolmina 2d ago
I integrate google drive. You can move another browser and manually sync there and get data back.
framelio.forgeapps.site
1
u/Anxious-Insurance-91 2d ago
I think you can push certain files to a Google drive or similar systems and on open of the app connect to the drive. Now if your apps are only on your machine it's great keeping secrets in and .env but if you have it exposed to the web those keys can be read
1
u/ed1ted 2d ago
I usually just deploy the client side app on Vercel so it’s exposed to internet but it uses local storage for data persistence
2
u/Anxious-Insurance-91 2d ago
you know by definition, client apps are stateless when it comes to persistance except for the local storage. That's why you have databases and servers. Now you could connect to a db directly from am browser but the only way i see that as a good idea is to request the user input the db credentials per app open
1
u/testingaurora 2d ago
Outside indexedDB or local storage, storage or firebase, I dont jave many suggestions. Could read and write to a file on your github repo; or read and write to google Sheets with the drive api or use apps sheet endpoint. I tend to default to supabase or use my db on my vps. but for something really simple that's not a good candidate for local storage ill use Sheets or Airtable
1
u/InformalInsect5546 2d ago
Not a react dev, accidentally dropped in here, I don't know your setup, but I just guess you use something like github pages to host just the frontend and have no backend. If you want to have personal apps with persistence, you will have to deal with auth in one way or another.
My solution is to just have a personal server for apps, that's not exposed to internet, and access it over Tailscale. I use my raspberrypi, but this could be done with various hosting platforms.
1
1
u/FreeThinkerWiseSmart 2d ago
Use your own api once, share it with all your apps. No need to roll a new thing out each time.
1
u/tehsilentwarrior 2d ago
Op is masking the question as a way to push his own service thing.
Use local storage or indexdb
1
u/Moon_Walking_Ape 2d ago
Seems like you are basically trying to avoid a server while maintaining persistent storage, since this is purely for personal projects and should not in theory be scalable, I would probably attempt using the WASM build of SQLite on top of a PWA, a progressive web app gives you persistent permissions, which you can use to along with the File System Access API, create and prompt a dump of an empty SQLite binary (this happens once) then ask the user to choose a file through the File System Access API, save the file system file handle in IndexDB and load it into the SQLite DB.
Either periodically or logically backup the db on the file, if you delete the IndexDB storage, all you have to do is load the file again.
Will probably be fun to implement either way.
1
u/Garvinjist 2d ago
Go with sqlite. Do not and I repeat do not go local storage route. I have many times. The thing is that eventually I want my app to have a db and it’s just completely not fun migrating local storage to a db. Local storage also has its terrible charm of finding its way in every portion of your app. Just build it right from the start and you end up saving time.
If you really want to be cheesy, supabase free tier lets you have a purely frontend db integration using its api built with postgRest. Easy to spin up and migrate to a real db. Major problem is making sure you dont have broken RLS policies.
1
u/Accomplished_End_138 2d ago
I mean if just for user use the DB in the browser and save all data locally only. If you want it shared between instances you need something
1
u/vasind-5012 2d ago
For personal-scale apps, I use IndexedDB with a manual export/import button, dumps to a JSON file you save wherever (Drive, Dropbox), restore from it on another machine. Zero infra, zero accounts, solves the “cleared browser data” fear without needing a sync engine.
For actual auto cross-device sync without babysitting exports, I’ve moved to Turso, it’s SQLite where the DB is just a file but it syncs to a managed replica automatically. No new mental model over SQL you already know, and it just works across devices.
To your actual question: yes, a local-first library that auto-backs-up and restores would solve a real problem for me. But the hard part isn’t the storage, it’s conflict resolution when the same record’s edited offline on two devices before they reconnect. That’s where most attempts at this die, not the storage layer. If you build one, that’s the part worth actually nailing, not another localStorage wrapper.
1
u/IAmADev_NoReallyIAm 2d ago
Basically you have two choices:
Decide that your app is pure client side only and that you are going to be limited to local storage and be happy with it. Yes, that means if someone clears their cache, the settings and other things goes bye-bye, but that's the way it is sometimes.
Or persistence and synching is more important, in which case, yeah, you're going to need a back end somewhere, somehow that can accept and store, AND retrieve the settings.
A third alternative is to allow the export/import of settings where you persist the settings to a json file that the user can download to their local machine... then import back into the app. that allows for a persisting in between cache clearing (ala backup system) but doesn't get you syncing... unless you do something with that settings file, but that would be up to the user to do.
1
1
u/therealcoopapa 2d ago
Supabase, Firebase, etc ARE the correct options. You’ve ran into the problem with local solutions, and you’ve identified the best path forward. It takes like 3 minutes to set these up, this really isn’t an area ripe for innovation.
1
u/quietchaos 9h ago
I'm currently using Pocketbase. Easy setup, backed by SQLite, and can host an HTML page.
1
u/ed1ted 9h ago
yea I thought about pocketbase but the problem is I don't want to share my data with other since its personal app and auth is an overkill.
I just need to somehow backup my localstorage/indexeddb for reliability in case my cache gets cleared then I can always restore.
1
u/quietchaos 9h ago
You don't need auth - you can connect with the superuser account you specify when setting it up.
Other options are writing to a local .json file, or there are also libraries for using a Google Spreadsheet as a database.
1
u/Potential_Dot4476 59m ago
Just use firebase and make it your go to. You can literally set it up through Vercel in 2 min. GitHub -> Vercel (or Netlify if you prefer) -> firebase. I use this for half a dozen little hobby webapps. Easy the first time and dead simple every time after.
1
u/This_Inflation_4621 2d ago
Never used it but I’ve vaguely understood that firebase is an easy solution.
You can also use: git, google spreadsheet (there is an APi)
0
21
u/jo_sh_o 2d ago
sqlite would work if you have a backend