Is IndexedDb dependent on cookie? - javascript

I am working on a prototype where we need to support offline data modification of web application, the application is expected to sync back the data when an internet connection is restored. I have taken a look at various HTML5 in-browser storage option and indexeddb looked like the one I wanted. But I am not sure if the data will be persisted between browser close. Is that possible? One more question if I delete the cookie of the browser, will data in indexedDb will be wiped out? My initial tests shows data gets deleted on cookie clear of browser.
If indexeddb is not a viable option, are there any other alternatives to it which can persist data when internet connection is not available?

As per specification database created with indexedDB should be persistent acrross navigation and browser session.
But current implementation is like persistent cookies. So removal of cookies might remove your database too.
As per google chrome indexedDB is a type of temporary storage.
Chrome: https://developer.chrome.com/apps/offline_storage
For microsoft & firefox it is persitent :
Microsoft: https://msdn.microsoft.com/en-in/hh563494.aspx
Firefox: https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB
Check supported browsers before use.
http://caniuse.com/#search=indexeddb

It isn't dependent on a cookie, though if you need to know who the user is (likely) you'll probably end up using a cookie of some variety...
As for offline sychronization... I thought about this a lot previously and created a project... The documentation for it is detailed and explains why and how... It may help, or at least give you things to think about. It has very recently been updated to support IndexedDB!
http://forbesmyester.github.io/SyncIt/index.html
In this space there is also RemoteStorage ( they were/are looking at using SyncIt + other bits in the project going forward ), Hood.ie and the commercial FireBase in this field.

Related

Are service workers ever removed automatically by the browser?

I've been trying to make PWAs that reliably work offline on and off for the past year, but every time I write a new service worker, it works as expected for a week or two and then just breaks (until reconnecting). I thought it was due to the site's data getting evicted, but the local storage is often intact when I reconnect to the internet so it can load. Recently I also had one of the service workers remain active, but its cache storage was deleted, as well as the other service workers (I've got multiple different sites on the same origin, some of which have service workers. It's my GitHub Pages).
According to the spec, it sounds like service workers should always remain registered unless the data for the whole origin is evicted. I also don't think my service workers are accidentally deleting their caches or unregistering themselves as the issue only happens after not using them for a while, in which case they aren't running. Clearing Chrome for Android's cache also doesn't break the PWAs when offline, so I don't think I'm manually doing anything that's breaking them. Clearing an individual PWA's storage and cache also doesn't break it.
The relevant sentence in the spec:
"A user agent must persistently keep a list of registered service worker registrations unless otherwise they are explicitly unregistered."
(the unregistered service workers also don't show up in chrome://serviceworker-internals/ )
Any ideas? Do you think this is a bug? I've mostly seen this in Chrome for Android, but I think I'll try some other browsers as well to check. Unfortunately I can't test any of this very well as it's quite unpredictable and takes weeks.
These are the 2 main sites to try, as I use the same template for a few, although I don't think it'll be that helpful:
https://hedgehog125.github.io/Bagel-PWA/
https://hedgehog125.github.io/Bagel-V2/ see https://github.com/hedgehog125/SvelteKit-Plugin-Versioned-Worker/blob/main/src/worker.js for the proper service worker template
Thanks for any input
Edit: I thought it would be worth a try to see if that first site still works in Firefox while offline. It does, despite not visiting it in Firefox for maybe 6 months. I guess this is a Chrome bug/feature then?
Edit: Updated the title

Persistent local storage for both Firefox and Chrome?

Looking for advice/options for having persistent local storage using both Firefox and Chrome allowing me to save 50MB+ data. I would be storing dynamic terrain data for a WebGL game, so it wouldn't be necessary for the server to send the whole data every time the player connects. I could just update the old parts.
I thought about using an IndexedDB however Chrome doesn't allow you to increase the quota (unlike Firefox) so I wouldn't be able to store any large data. Chrome allows you to use the FileSystem API which would solve my issue however Firefox does not support it.
So it seems either way it wouldn't work. Is my only option to use the FileSystem API for Chrome and the IndexedDB for Firefox? Does anyone have any better ideas?
This info is what I've read from Mozilla's Blog and Google's Dev Site but that may be outdated now, so please feel free to correct me. Thanks!
I agree with the other comments about caching and the Chrome/Firefox marketplaces, and they may ultimately be better solutions for you. However, to answer your original question...
IndexedDB in Chrome is definitely not limited to 5 MB. You can store far more than 50 MB in IndexedDB in both Firefox and Chrome, assuming the user has enough hard drive space. Higher amounts of IndexedDB storage are regularly reached in this game I wrote. On my computer, I currently have over 500 MB stored in IndexedDB in Chrome for that one domain.
You did correctly link to https://developers.google.com/chrome/whitepapers/storage and it is quite confusing, but as I understand it, basically the upper limit is 10% of the free space on the hard drive. Another caveat described on that page is that IndexedDB is technically "temporary" storage that the browser might delete if space is running low, but in practice this seems to rarely happen (YMMV).
localStorage is limited to 5 MB (I think this was on Chrome) and you can request more space for every new 5 MB through dialog boxes.
Both localStorage and IndexedDb are created for interactive data. Because it looks like the data is not modified on the client-side your options are
Using the application cache (as mentioned in the comment)
Serving the data with cache forever HTTP headers (like 10 years), have unique URLs for new resource versions and let the browser re-download the data when it goes out of the cache (recommended)
Deploy your HTML5 application as a web app, downloads available from Chrome Store and Firefox Marketplace

offline, cross-tab communication (javascript-only)

Is it possible to find foreign instances of certain website? Ofc theese are independently opened tabs (not by window.open). I need to prevent user from opening 2 tabs, and send message to previously opened tab to inform that it's impossible to open 2 tabs. 2 Intependent tabs may break page offline storage and webSQL structure, so that I can't allow people to use 2 tabs. It's also semi-offline app so it needs to be client-side solution.
You can communicate across tabs using localStorage. Every time you write a value, a "storage" event is fired on the window object on every tab (except the current one).
http://diveintohtml5.info/storage.html
Scroll down to "Tracking changes in the html5 storage area"
The event will include event.key, event.newValue, event.oldValue.
This only works in modern browsers.
In 2021, you can use service worker:
https://github.com/gyteng/service-worker-event
notice: service worker only works in https protocol
localStorage can be used to track windows. You should take into account a situation when window crashes - it will leave the garbage in localStorage.
Accessing a common resource from several windows simultaneously may be done by mutex based on localStorage.
I've recently published the interwindow communication library (all features are described in readme). It provides thread-safe data sharing, cross-window locks and event broadcasting. It also solves some IE issues.
Broadcast Channel is design for this
https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API
but the native api only support modern browsers.
there is a npm package support all old browsers as well
https://www.npmjs.com/package/broadcast-channel
You don't have control over that. The user can do basically whatever he/she wants on the computer.

Client side local storage of data

I want to store some data client side. Cookies are my first inclination, but they get sent with every request, right? Is there a way to store data without it being transferred? I don't necessarily want to add 10-20k of overhead for every request. Is the only alternative HTML 5 webstorage and how many browsers have adopted that?
html5 storage is widely deployed
HTML5 STORAGE SUPPORT
IE FIREFOX SAFARI CHROME OPERA IPHONE ANDROID
8.0+ 3.5+ 4.0+ 4.0+ 10.5+ 2.0+ 2.0+
you can find out more # http://diveintohtml5.ep.io/storage.html
No, not all cookies get sent with every request. You can check to see if a cookie exists, if not create it, and if so, read it. Cookies are still a good cross-browser option for small amounts of data.
http://fsojs.com supports robust file storage client-side, but only works with Chrome at the moment
As you have mentioned, cookies are an options and so is web storage in the HTML5 spec. There's also the ability to use Flash to store data with the added benefit that this data persists across multiple browsers on the same machine, but the drawback that you'll need a fallback for users who don't have Flash.
Personally, keeping the data on the server (identified by the session id or cookie) would be my way to do it, you have control of the data and don't have to worry about losing it when the user clears their cache or switches machines/devices. It's also the most fault-tolerant because it doesn't rely on browser features and/or plugins (other than perhaps cookies).
One more thing, if you're looking for an abstraction of client-side data storage that uses all of the above (cookies, flash, web storage) check out Evercookie

Different browser behaviour between localStorage/sessionStorage and cookies

This is not so much a technical question as a question of practice: browser storage doesn't seem to have the same browser behaviour as cookies.
For example:
In Firefox 3.6, sessionStorage is not shared between tabs within the same browser session.
localStorage can never be set to expire, while sessionStorage can never persist.
If a site uses cookies for the session, they are shared between tabs.
If a cookie is set to expire, then it expires after a certain date.
It makes sense that it is not 'like for like', however this means that we may need to mix and match our variable storage solutions depending on need. Your thoughts and opinions on the benefits/pitfalls of either would be appreciated.
Background:
On the website we are currently developing, we decided to implement progressive enhancement using browser storage (sessionStorage and localStorage) with a cookie fall-back. Our reason for doing this is simply as a learning exercise, but moving forward this should help us on mobile platforms and situations where cookies are not usable (we are already storing our assets on a cookie-less domain, so this isn't a motivator).
To do this, we have created a class which has set, get, remove and clear methods which store the application variables within a JSON string (this allows us to group values in a hierarchy). For browsers which don't have a JSON parser we use Crockfords JSON plugin.
At run time the storage class works out if the user's browser supports browser storage, otherwise sets the functions to write to cookies instead. Due to the inconsistencies already highlighted (plus others I am unaware of), this 'like for like' progressive enhancement is actually false.
Edit: Another browser vaguary: if IE 8 is running in IE 7 standards mode it supports localStorage and sessionStorage, where standalone IE 7 does not(!).

Categories

Resources