OFFLINE PWA JOURNEY TO THE FUTURE USING REACT AND NODEJS
{ "name": "Ilia Idakiev", "experience": [ "Lecturer in 'Advanced JS' @ FMI", "Developer / Manager / Owner @ HNS", "Project Contractor / Consultant", "2 Angular Courses @ HB (2016 - 2017)", "Private Courses" ], "involvedIn": [ "SofiaJS", "BeerJS", "Angular Sofia” ] } ABOUT ME
I 💜 VINYL
WHY ARE WE HERE TODAY?
WHAT ARE PWA? FAST - Respond quickly to user interactions with silky smooth animations and no janky scrolling. RELIABLE - Load instantly and never show the downasaur, even in uncertain network conditions. ENGAGING - Feel like a natural app on the device, with an immersive user experience.
13% 87% WEB APPS NATIVE APPS USAGE STATISTICS ON MOBILE DEVICES Source: Google
SOFTWARE DISTRIBUTION
0 APPS 100 WEB SITES AVERAGE USER STATS PER MONTH Source: Google
40% OF USERS BOUNCE FROM SITES THAT TAKE MORE THAN 3 SEC TO LOAD Source: Google
SERVICE WORKERS
OFFLINE PROGRESSIVE WEB APPLICATIONS SERVICE WORKERS ▸ Runs separately from the main browser thread ▸ Designed to be fully asynchronous ▸ Programmable network proxy ▸ Runs only over HTTPS ▸ Becomes idle when not in use and restarts when it's next needed.
OFFLINE PROGRESSIVE WEB APPLICATIONS ADVANCED FEATURES ▸ Notifications API - Display and interact with notifications using the operating system's native notification system. ▸ Push API: Subscribe to a push service and receive push messages. Push messages are delivered to a service worker, which can use the information in the message to update the local state or display a notification to the user. Because service workers run independently of the main app, they can receive and display notifications even when the browser is not running.
OFFLINE PROGRESSIVE WEB APPLICATIONS ADVANCED FEATURES ▸ Background Sync API: Defer actions until the user has stable connectivity. This is useful to ensure that whatever the user wants to send is actually sent. This API also allows servers to push periodic updates to the app so the app can update when it's next online. ▸ Channel Messaging API: Lets web workers and service workers communicate with each other and with the host application.
SERVICE WORKER LIFECYCLE
OFFLINE PROGRESSIVE WEB APPLICATIONS 1. REGISTRATION ▸ The scope of the service worker determines which files the service worker controls. The default scope is the location of the service worker file, and extends to all directories below. An arbitrary scope can also be set by passing in an additional parameter when registering.
OFFLINE PROGRESSIVE WEB APPLICATIONS 2. INSTALLATION ▸ This occurs if the service worker is considered to be new by the browser. ▸ During the install, service workers can precache parts of a web app so that it loads instantly the next time a user opens it.
OFFLINE PROGRESSIVE WEB APPLICATIONS 3. ACTIVATION ▸ If there are any open pages controlled by the previous service worker, the new service worker enters a waiting state. ▸ The new service worker only activates when there are no longer any pages loaded that are still using the old service worker. This ensures that only one version of the service worker is running at any given time. ▸ When the new service worker activates, an activate event is triggered in the activating service worker. This event listener is a good place to clean up outdated caches.
OFFLINE PROGRESSIVE WEB APPLICATIONS ADDITIONAL INFORMATION ‣ The clients.claim() method allows an active service worker take control of uncontrolled clients. ▸ skipWaiting() - kill existing service workers and activate the new service worker. ‣ The clients.matchAll() method resolves to an array of all controlled clients. ‣ A client can access its controller by navigator.serviceWorker.controller ‣ Messages between service worker and client are send using .postMessage() method (used on client or controller respectively)
OFFLINE PROGRESSIVE WEB APPLICATIONS OTHER EVENTS THAT SW CAN LISTEN FOR ▸ message - service worker can receive information from other scripts ▸ fetch - intercept requests. ▸ push - when a (Web Push Protocol) message is received. ▸ sync - ask for an event to be fired when the user has connectivity 
 (https://wicg.github.io/BackgroundSync/spec/)
OFFLINE PROGRESSIVE WEB APPLICATIONS SERVICE WORKER UPDATE TRIGGERING ▸ On navigation to an in-scope page. ▸ On functional events such as push and sync, unless there's been an update check within the previous 24 hours. ▸ On calling .register() only if the service worker URL has changed.
OFFLINE PROGRESSIVE WEB APPLICATIONS SW UPDATE LIFECYCLE
OTHER EVENTS
NOTIFICATION API
OFFLINE PROGRESSIVE WEB APPLICATIONS CHECK IF BROWSER SUPPORTS NOTIFICATION API
OFFLINE PROGRESSIVE WEB APPLICATIONS REQUESTING PERMISSIONS FOR NOTIFICATION API ▸ Only prompt when it's obvious to the user why you need extra privileges
OFFLINE PROGRESSIVE WEB APPLICATIONS USING NOTIFICATION API
OFFLINE PROGRESSIVE WEB APPLICATIONS NOTIFICATION OPTIONS ▸ The BODY option adds a main description to the notification. It should give the user enough information to decide how to act on it. ▸ The ICON option attaches an image to make the notification more visually appealing, but also more relevant to the user. ▸ The VIBRATE option specifies a vibration pattern for a phone receiving the notification. ▸ The DATA option attaches custom data to the notification, so that the service worker can retrieve it when the user interacts with the notification. For instance, adding a unique "id" or "key" option to the data allows us to determine which notification was clicked when the service worker handles the click event.
OFFLINE PROGRESSIVE WEB APPLICATIONS LISTENING FOR NOTIFICATION CLICKS
OFFLINE PROGRESSIVE WEB APPLICATIONS LISTENING FOR NOTIFICATION CLOSE
GOING OFFLINE
OFFLINE PROGRESSIVE WEB APPLICATIONS CACHE API ▸ Lets us create stores of responses keyed by request. ▸ Exposed on the window so it accessed from anywhere in your scripts via "caches". ▸ waitUntil extends the lifetime of the install event until the passed promise resolves successfully. If the promise rejects, the installation is considered a failure and this service worker is abandoned (if an older version is running, it stays active).
OFFLINE PROGRESSIVE WEB APPLICATIONS CACHE FALLING BACK TO THE NETWORK ▸ To serve content from the cache and make your app available offline you need to intercept network requests and respond with files stored in the cache.
OFFLINE PROGRESSIVE WEB APPLICATIONS ALL APPROACHES ▸ cache only ▸ network only ▸ cache falling back to network ▸ network falling back to cache ▸ cache then network
OFFLINE PROGRESSIVE WEB APPLICATIONS SERVICE WORKERS
OFFLINE PROGRESSIVE WEB APPLICATIONS APPLICATION SHELL ▸ An application shell is the minimal HTML, CSS, and JavaScript powering a user interface
INDEXEDDB API
OFFLINE PROGRESSIVE WEB APPLICATIONS INDEXEDDB API ▸ IndexedDB is a low-level API for client-side storage of significant amounts of structured data, including files/blobs. ▸ This API uses indexes to enable high performance searches of this data.
OFFLINE PROGRESSIVE WEB APPLICATIONS CREATING OBJECT STORE
OFFLINE PROGRESSIVE WEB APPLICATIONS CREATING OBJECT STORE WITH KEYS
OFFLINE PROGRESSIVE WEB APPLICATIONS INDEXEDDB TERMS ▸ Database - This is the highest level of IndexedDB. It contains the object stores, which in turn contain the data you would like to persist. ▸ Object store - An object store is an individual bucket to store data. You can think of object stores as being similar to tables in traditional relational databases. ▸ Index - An Index is a kind of object store for organizing data in another object store (called the reference object store) by an individual property of the data. The index is used to retrieve records in the object store by this property. For example, if you're storing people, you may want to fetch them later by their name, age, or favorite animal. ▸ Operation - An interaction with the database. ▸ Transaction - A transaction is wrapper around an operation, or group of operations, that ensures database integrity. If one of the actions within a transaction fail, none of them are applied and the database returns to the state it was in before the transaction began.
PROMISES?
https://github.com/jakearchibald/idb
HOW TO IMPORT EXTERNAL SCRIPTS?
POUCHDB POUCHDB IS AN OPEN-SOURCE JAVASCRIPT DATABASE INSPIRED BY APACHE COUCHDB THAT IS DESIGNED TO RUN WELL WITHIN THE BROWSER. POUCHDB WAS CREATED TO HELP WEB DEVELOPERS BUILD APPLICATIONS THAT WORK AS WELL OFFLINE AS THEY DO ONLINE. 
 IT ENABLES APPLICATIONS TO STORE DATA LOCALLY WHILE OFFLINE, THEN SYNCHRONIZE IT WITH COUCHDB
INSTALLABLE WEB APPS
OFFLINE PROGRESSIVE WEB APPLICATIONS APPLICATION MANIFEST JSON ▸ Web app manifests provide the ability to save a site bookmark to a device's home screen. When a site is launched this way: ▸ It has a unique icon and name so that users can distinguish it from other sites. ▸ It displays something to the user while resources are downloaded or restored from cache. ▸ It provides default display characterstics to the browser to avoid too abrupt transition when site resources become available.
OFFLINE PROGRESSIVE WEB APPLICATIONS SIMPLE MANIFEST JSON
OFFLINE PROGRESSIVE WEB APPLICATIONS APP MANIFEST TOOLS ▸ http://realfavicongenerator.net/ ▸ http://preview.pwabuilder.com
WEB PUSH API
OFFLINE PROGRESSIVE WEB APPLICATIONS WEB PUSH API 1. A device downloads your web app containing an already created publicKey, referred to in scripts as the applicationServerKey. Your web app installs a service worker. 2. During the subscription flow the browser contacts the messaging server to create a new subscription and returns it to the app. Note: You don't need to know the URL of the message server. Each browser vendor manages it's own message server for its browser. 3. After the subscription flow, your app passes a subscription object back to your app server. 4. At some later point, your app server sends a message to the messaging server, which forwards it to the recipient.
WE DON'T NEED FIREBASE / GOOGLE CLOUD MESSAGING SENDER ID ( GCM_SENDER_ID ) ANYMORE!
OFFLINE PROGRESSIVE WEB APPLICATIONS VOLUNTARY APPLICATION SERVER IDENTIFICATION (VAPID) ▸ Your application server creates a public/private key pair. The public key is given to your web app. ▸ When the user elects to receive pushes, add the public key to the subscribe() call's options object. ▸ When your app server sends a push message, include a signed JSON Web Token along with the public key.
OFFLINE PROGRESSIVE WEB APPLICATIONS OTHER SERVICE WORKER APIS ▸ Payment Request API ▸ Credential Management API
OFFLINE PROGRESSIVE WEB APPLICATIONS ▸ Payment Request API Workflow
IN PURSUIT OF SPEED
OFFLINE PROGRESSIVE WEB APPLICATIONS SERVER SIDE RENDERING ▸ First Meaningful Paint - The time at which the user feels that the primary content of the page is visible. ▸ Rendering front-end JavaScript applications on the server.
TESTING OUR WEB APPS
QUESTIONS
FOLLOW ME @ http://github.com/iliaidakiev/
THANK YOU!

Offline progressive web apps with NodeJS and React

  • 1.
    OFFLINE PWA JOURNEY TOTHE FUTURE USING REACT AND NODEJS
  • 2.
    { "name": "Ilia Idakiev", "experience":[ "Lecturer in 'Advanced JS' @ FMI", "Developer / Manager / Owner @ HNS", "Project Contractor / Consultant", "2 Angular Courses @ HB (2016 - 2017)", "Private Courses" ], "involvedIn": [ "SofiaJS", "BeerJS", "Angular Sofia” ] } ABOUT ME
  • 3.
  • 4.
    WHY ARE WEHERE TODAY?
  • 5.
    WHAT ARE PWA? FAST- Respond quickly to user interactions with silky smooth animations and no janky scrolling. RELIABLE - Load instantly and never show the downasaur, even in uncertain network conditions. ENGAGING - Feel like a natural app on the device, with an immersive user experience.
  • 6.
    13% 87% WEB APPS NATIVE APPS USAGESTATISTICS ON MOBILE DEVICES Source: Google
  • 7.
  • 8.
    0 APPS 100 WEBSITES AVERAGE USER STATS PER MONTH Source: Google
  • 9.
    40% OF USERSBOUNCE FROM SITES THAT TAKE MORE THAN 3 SEC TO LOAD Source: Google
  • 10.
  • 11.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS SERVICE WORKERS ▸ Runs separately from the main browser thread ▸ Designed to be fully asynchronous ▸ Programmable network proxy ▸ Runs only over HTTPS ▸ Becomes idle when not in use and restarts when it's next needed.
  • 12.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS ADVANCED FEATURES ▸ Notifications API - Display and interact with notifications using the operating system's native notification system. ▸ Push API: Subscribe to a push service and receive push messages. Push messages are delivered to a service worker, which can use the information in the message to update the local state or display a notification to the user. Because service workers run independently of the main app, they can receive and display notifications even when the browser is not running.
  • 13.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS ADVANCED FEATURES ▸ Background Sync API: Defer actions until the user has stable connectivity. This is useful to ensure that whatever the user wants to send is actually sent. This API also allows servers to push periodic updates to the app so the app can update when it's next online. ▸ Channel Messaging API: Lets web workers and service workers communicate with each other and with the host application.
  • 14.
  • 15.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS 1. REGISTRATION ▸ The scope of the service worker determines which files the service worker controls. The default scope is the location of the service worker file, and extends to all directories below. An arbitrary scope can also be set by passing in an additional parameter when registering.
  • 16.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS 2. INSTALLATION ▸ This occurs if the service worker is considered to be new by the browser. ▸ During the install, service workers can precache parts of a web app so that it loads instantly the next time a user opens it.
  • 17.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS 3. ACTIVATION ▸ If there are any open pages controlled by the previous service worker, the new service worker enters a waiting state. ▸ The new service worker only activates when there are no longer any pages loaded that are still using the old service worker. This ensures that only one version of the service worker is running at any given time. ▸ When the new service worker activates, an activate event is triggered in the activating service worker. This event listener is a good place to clean up outdated caches.
  • 18.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS ADDITIONAL INFORMATION ‣ The clients.claim() method allows an active service worker take control of uncontrolled clients. ▸ skipWaiting() - kill existing service workers and activate the new service worker. ‣ The clients.matchAll() method resolves to an array of all controlled clients. ‣ A client can access its controller by navigator.serviceWorker.controller ‣ Messages between service worker and client are send using .postMessage() method (used on client or controller respectively)
  • 19.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS OTHER EVENTS THAT SW CAN LISTEN FOR ▸ message - service worker can receive information from other scripts ▸ fetch - intercept requests. ▸ push - when a (Web Push Protocol) message is received. ▸ sync - ask for an event to be fired when the user has connectivity 
 (https://wicg.github.io/BackgroundSync/spec/)
  • 20.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS SERVICE WORKER UPDATE TRIGGERING ▸ On navigation to an in-scope page. ▸ On functional events such as push and sync, unless there's been an update check within the previous 24 hours. ▸ On calling .register() only if the service worker URL has changed.
  • 21.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS SW UPDATE LIFECYCLE
  • 22.
  • 23.
  • 24.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS CHECK IF BROWSER SUPPORTS NOTIFICATION API
  • 25.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS REQUESTING PERMISSIONS FOR NOTIFICATION API ▸ Only prompt when it's obvious to the user why you need extra privileges
  • 26.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS USING NOTIFICATION API
  • 27.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS NOTIFICATION OPTIONS ▸ The BODY option adds a main description to the notification. It should give the user enough information to decide how to act on it. ▸ The ICON option attaches an image to make the notification more visually appealing, but also more relevant to the user. ▸ The VIBRATE option specifies a vibration pattern for a phone receiving the notification. ▸ The DATA option attaches custom data to the notification, so that the service worker can retrieve it when the user interacts with the notification. For instance, adding a unique "id" or "key" option to the data allows us to determine which notification was clicked when the service worker handles the click event.
  • 28.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS LISTENING FOR NOTIFICATION CLICKS
  • 29.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS LISTENING FOR NOTIFICATION CLOSE
  • 30.
  • 31.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS CACHE API ▸ Lets us create stores of responses keyed by request. ▸ Exposed on the window so it accessed from anywhere in your scripts via "caches". ▸ waitUntil extends the lifetime of the install event until the passed promise resolves successfully. If the promise rejects, the installation is considered a failure and this service worker is abandoned (if an older version is running, it stays active).
  • 32.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS CACHE FALLING BACK TO THE NETWORK ▸ To serve content from the cache and make your app available offline you need to intercept network requests and respond with files stored in the cache.
  • 33.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS ALL APPROACHES ▸ cache only ▸ network only ▸ cache falling back to network ▸ network falling back to cache ▸ cache then network
  • 34.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS SERVICE WORKERS
  • 35.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS APPLICATION SHELL ▸ An application shell is the minimal HTML, CSS, and JavaScript powering a user interface
  • 36.
  • 37.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS INDEXEDDB API ▸ IndexedDB is a low-level API for client-side storage of significant amounts of structured data, including files/blobs. ▸ This API uses indexes to enable high performance searches of this data.
  • 38.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS CREATING OBJECT STORE
  • 39.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS CREATING OBJECT STORE WITH KEYS
  • 40.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS INDEXEDDB TERMS ▸ Database - This is the highest level of IndexedDB. It contains the object stores, which in turn contain the data you would like to persist. ▸ Object store - An object store is an individual bucket to store data. You can think of object stores as being similar to tables in traditional relational databases. ▸ Index - An Index is a kind of object store for organizing data in another object store (called the reference object store) by an individual property of the data. The index is used to retrieve records in the object store by this property. For example, if you're storing people, you may want to fetch them later by their name, age, or favorite animal. ▸ Operation - An interaction with the database. ▸ Transaction - A transaction is wrapper around an operation, or group of operations, that ensures database integrity. If one of the actions within a transaction fail, none of them are applied and the database returns to the state it was in before the transaction began.
  • 41.
  • 42.
  • 43.
    HOW TO IMPORTEXTERNAL SCRIPTS?
  • 44.
    POUCHDB POUCHDB IS ANOPEN-SOURCE JAVASCRIPT DATABASE INSPIRED BY APACHE COUCHDB THAT IS DESIGNED TO RUN WELL WITHIN THE BROWSER. POUCHDB WAS CREATED TO HELP WEB DEVELOPERS BUILD APPLICATIONS THAT WORK AS WELL OFFLINE AS THEY DO ONLINE. 
 IT ENABLES APPLICATIONS TO STORE DATA LOCALLY WHILE OFFLINE, THEN SYNCHRONIZE IT WITH COUCHDB
  • 45.
  • 46.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS APPLICATION MANIFEST JSON ▸ Web app manifests provide the ability to save a site bookmark to a device's home screen. When a site is launched this way: ▸ It has a unique icon and name so that users can distinguish it from other sites. ▸ It displays something to the user while resources are downloaded or restored from cache. ▸ It provides default display characterstics to the browser to avoid too abrupt transition when site resources become available.
  • 47.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS SIMPLE MANIFEST JSON
  • 48.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS APP MANIFEST TOOLS ▸ http://realfavicongenerator.net/ ▸ http://preview.pwabuilder.com
  • 49.
  • 50.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS WEB PUSH API 1. A device downloads your web app containing an already created publicKey, referred to in scripts as the applicationServerKey. Your web app installs a service worker. 2. During the subscription flow the browser contacts the messaging server to create a new subscription and returns it to the app. Note: You don't need to know the URL of the message server. Each browser vendor manages it's own message server for its browser. 3. After the subscription flow, your app passes a subscription object back to your app server. 4. At some later point, your app server sends a message to the messaging server, which forwards it to the recipient.
  • 51.
    WE DON'T NEEDFIREBASE / GOOGLE CLOUD MESSAGING SENDER ID ( GCM_SENDER_ID ) ANYMORE!
  • 52.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS VOLUNTARY APPLICATION SERVER IDENTIFICATION (VAPID) ▸ Your application server creates a public/private key pair. The public key is given to your web app. ▸ When the user elects to receive pushes, add the public key to the subscribe() call's options object. ▸ When your app server sends a push message, include a signed JSON Web Token along with the public key.
  • 53.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS OTHER SERVICE WORKER APIS ▸ Payment Request API ▸ Credential Management API
  • 54.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS ▸ Payment Request API Workflow
  • 55.
  • 56.
    OFFLINE PROGRESSIVE WEBAPPLICATIONS SERVER SIDE RENDERING ▸ First Meaningful Paint - The time at which the user feels that the primary content of the page is visible. ▸ Rendering front-end JavaScript applications on the server.
  • 57.
  • 60.
  • 61.
    FOLLOW ME @http://github.com/iliaidakiev/
  • 62.