Published Feb 06 2021
Psssst! The 2023 WEB DEVELOPMENT BOOTCAMP is starting on FEBRUARY 01, 2023! SIGNUPS ARE NOW OPEN to this 10-weeks cohort course. Learn the fundamentals, HTML, CSS, JS, Tailwind, React, Next.js and much more! ✨
I was thinking about a new web application (still in the idea phase) and I was thinking that I would like it to be 100% frontend. I don’t have a need for a backend, and I thought to use IndexedDB as the main database for the application data.
See my complete IndexedDB tutorial
IndexedDB is a W3C standard and it’s built into the browser. The fact that it’s built into the browser should give you the following advantages:
If you think about using it, there are some downsides that might change your mind.
The first and bigger one is that Safari will wipe out IndexedDB (and other local storage) after 7 days of inactivity on the site. This means that if you don’t visit the site for more than 7 days, your data is gone. On iOS and on the Mac, too.
All the other browsers have a way to ask users permission to persist the data, but Safari does not and this is a big show stopper.
Other downsides? You do not have access to the data unless in the moment the user opens the app, which prevents to add some kind of functionality that for example relies on using this data in the backend when the user is not using the app.
Another problem of this approach is cross-device sync. IndexedDB lives inside the browser, so if you access the app from your phone, the data cannot be accessed, without creating some kind of syncing service. Which.. is a backend, in the end.
So I think the only option, without creating a half-assed application that is not usable by Safari is to have a backend and store the data there.
And think about IndexedDB as good for temporary data, not long-term storage.