Slide 1

Slide 1 text

Storage for the web For offline support app

Slide 2

Slide 2 text

Even though there are many option,

Slide 3

Slide 3 text

When saving data locally in web, what do we use?

Slide 4

Slide 4 text

Well, … or at least for me :P

Slide 5

Slide 5 text

What to store? application resources (HTML, JavaScript, CSS, images, etc.) data (user data, news articles, etc.)

Slide 6

Slide 6 text

What should I use? ▪ For the network resources necessary to load your app and file-based content, use the Cache Storage API ▪ For other data, use IndexedDB

Slide 7

Slide 7 text

What about other storage mechanisms? ▪ SessionStorage ▪ LocalStorage ▪ Cookies ▪ WebSQL

Slide 8

Slide 8 text

LocalStorage should be avoided because it is synchronous and will block the main thread. It is limited to about 5MB and can contain only strings. LocalStorage is not accessible from web workers or service workers.

Slide 9

Slide 9 text

SessionStorage is tab specific, and scoped to the lifetime of the tab. It may be useful for storing small amounts of session specific information It should be used with caution because it is synchronous and will block the main thread. It is limited to about 5MB and can contain only strings. Because it is tab specific, it is not accessible from web workers or service workers.

Slide 10

Slide 10 text

Cookies ▪ have their uses, but should not be used for storage. ▪ Cookies are sent with every HTTP request, so storing anything more than a small amount of data will significantly increase the size of every web request. ▪ They are synchronous, and are not accessible from web workers. ▪ Like LocalStorage and SessionStorage, cookies are limited to only strings.

Slide 11

Slide 11 text

WebSQL ▪ Was a wrapper of sqlite for web ▪ should not be used, and existing usage should be migrated to IndexedDB. ▪ Support has been removed from almost all major browsers. ▪ The W3C stopped maintaining the Web SQL spec in 2010, with no plans to further updates planned

Slide 12

Slide 12 text

IndexedDB ▪ asynchronous, and will not block the main thread ▪ They're accessible from the window object, web workers, and service workers, making it easy to use them anywhere in your code

Slide 13

Slide 13 text

How much can I store? In short, a lot, at least a couple of hundred megabytes, and potentially hundreds of gigabytes or more

Slide 14

Slide 14 text

▪ Chrome allows the browser to use up to 80% of total disk space ▪ Internet Explorer 10 and later can store up to 250MB ▪ Firefox allows the browser to use up to 50% of free disk space ▪ Safari (both desktop and mobile) appears to allow about 1GB.

Slide 15

Slide 15 text

How can I check how much storage is available?

Slide 16

Slide 16 text

How does eviction work? Best Effort ▪ Chromium-based browsers -> clearing all site data from the least recently used origin first, then the next, until the browser is no longer over the limit. ▪ Internet Explorer 10+ -> will not evict data but will prevent the origin from writing any more ▪ Firefox -> clearing all site data from the least recently used origin first, then the next, until the browser is no longer over the limit. ▪ Safari previously did not evict data, but recently implemented a new seven- day cap on all writable storage. This means Safari will evict all content from the cache after seven days of Safari use if the user does not interact with the site

Slide 17

Slide 17 text

How does eviction work? ▪ Persistent

Slide 18

Slide 18 text

Conclusion Gone are the days of limited storage and prompting the user to store more and more data. Sites can store effectively all of the resources and data they need to run. Using the StorageManager API you can determine how much is available to you, and how much you've used. And with persistent storage, unless the user removes it, you can protect it from eviction.

Slide 19

Slide 19 text

Bonus Example App