Taking your web application offline
A Service Worker is basically a javascript file that runs separately from the main browser.
This allows for several advanced features that can be utilized to help take you application offline
Most notable of these features are caching resources offline, intercepting network requests, and delivering push messages
https://developers.google.com/web/ilt/pwa/introduction-to-service-worker
There are two ways to cache resources with service workers: Pre-caching and runtime Caching
Pre-caching: Define a list of files for the service worker to fetch in the background when your app first registers your service worker
Runtime Caching: Cache files/data as needed as your application is running.
There are multiple way to cache data with runtime caching:
Cache Only: Only serve files from the cache
Network Only: Never cache any data and always go straight to the server
Cache First: Check the cache to see if the data exists, if not then go to the server, optionally cache data afterward
Network First: Go to the server first, then cache any data that returns from the server
Service workers can intercept network requests for the purposes of caching, but a special network request can be made that will wait until there's a network connection before being sent to the server. This is a background sync.
Typically, there's only one background sync event and multiple request can be put "on hold" until the background sync event can be fired.
Because the service worker is in a separate thread from the main javascript files, data cannot be transferred from one thread to another easily.
The postMessage method or the Message Channel API can be used to send data from one thread to another and back again. Both methods can initiated from either side.
Service Workers persist the lifetime of the browser being open, even if the user is no longer on the page the service worker was registered to. This allows messages from the server to be sent to the service worker which can then notify the user of new data. Clicking on this notification, can optionally open the original page again.
This does require a separate server to handle push notification. This is a separate server than the main application server.
Service workers will also need to subscribe with the PN server to be able to receive notifications.
Since service workers are not part of the main page thread they:
Do not have access to the DOM of the original page. Messages must be used to interact with the DOM of the registering page.
XHR and localStorage cannot be used. IndexedDB is an alternative to localStorage. IndexedDB is a storage DB much like localStorage but is completely asynchronous.
Service Workers must be run over HTTPS (unless in development)
Service workers become idle when not in use and restarts when it's next needed. You cannot rely on a global state to persist between events.
Service workers make extensive use of Promises.
Service workers must be "registered" before they can be used. Multiple registrations from the same page is no problem.