I’m looking to write a simple productivity app for daily programming/freelancing tasks. It’ll be fully static html/bootstrap/js browser running app without any backend. The idea is to open source it later and host it on github pages.
For storing the actual data (tasks, milestones, hours worked, etc.), I’m a bit confused between available options like localStorage and indexeddb. I’d have ideally preferred an SQL database and there seems to be one called “WebSQL” but I’ve heard that it’s depreciated by standards bodies and not recommended for most projects.
On the other hand, we have key-value databases like localStorage and indexeddb which I can structure my app logic around. However, I’m concerned about the space limits here. My research so far suggests that Indexeddb seems to have more flexible limits but a bit cumbersome to use compared to localStorage which is easier to use but you’ll reach the storage limits quicker! But the data on space limitations seem quite vague and nebulous.
My question here is:
- Which is the ideal database to use in this situation?
- What are the realistic space limitations for both these storage methods?
Something you have not mentioned and perhaps not thought about is if you need the data in just the one system that the browser is executing in or if you need the data to be available in multiple systems, at least in a desktop and a phone or something like that.
There is much information available from a search and I do not know how much of it is important to you. Just understand that local storage might not be the same as
localStorage, that caused me a little confusion.
You will find articles and posts explaining that localStorage and indexeddb are not both simply key-value databases. I think localStorage provides simple key-value databases but you should read the material yourself. The more complicated one is more powerful. Use the simple one if it satisfies your requirements otherwise use the more powerful one. If you need help choosing which one then the help you get will be as good as the requirements you provide.
That’s indeed something on the back of my mind. I’d preferably want to manage the tasks on my laptop browser but also be able to view them on my Android browser too - probably a sync solution whereby the localStorage/indexeddb can be synced with a backend cloud API (Google Drive/Dropbox/etc) should do the trick. But that will come at the later stage, not now.
If they are (nearly) always connected to the internet then there is no synchronization necessary; or at least not by you. They both can use the same cloud database as if the database is local.
Accessing localStorage is a synchronous operation; potentially slowing things down if you do a lot of read/writes. And you already know about the size limitation.
A self-contained PHP setup is probably overkill for internal to an app; keep in mind there that either the PHP agent must be running within a web server, or you would have to have your app invoke the CLI, but then the idea of sessions goes out the window, so you’d have to send a fair bit of data into the CLI to get it to fake one.
I can’t say i’ve ever used indexeddb, so I cannot comment there.
I would never recommend building a client application only if you want to share data on multiple devices.
When you use multiple clients there should always be a server who is synchronizing them.
Of course you can only use a cloud database but as already mentioned this is not very secure.
Also, how would you like to install the local app? Will you deploy a zip package which must be unpacked in a local folder and then you call the index.html? That doesn’t look very user friendly to me.
What about if you change something? How will you be sure that not an old version is running on one device while a newer is running on another device. In worse case you have changed the database schema for the new version. The old version will crash then.
Of course this might be only a small application for you but you want to make it public on Github. So your intend is, that others will use it too.
For me you should not try to make a web app a “not web app” by removing the web server, which is the main part of a web app. Even because getting a costless Webserver anywhere is not a big deal.