Service workers and their role in PWAs
•Download as PPTX, PDF•
0 likes•73 views
Progressive Web Applications have gained unparalleled momentum in the tech world and are currently one of the hottest trends in Web Development. Find out how PWA attempts to combine features offered by most modern browsers with the benefits of mobile experience and how service workers make them fast, reliable & engaging.
Report
Share
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
More Related Content
What's hot
What's hot (20)
Similar to Service workers and their role in PWAs
Similar to Service workers and their role in PWAs (20)
Recently uploaded
Recently uploaded (20)
Service workers and their role in PWAs
- 1. Service Workers & their role in PWAs PHP UK CONFERENCE 2018
- 2. Hi! I’m Ipsha. Mozilla Tech Speaker @ipsha21
- 3. WEB vs NATIVE? Not all decisions are as easy as this..
- 5. “Progressive Web Apps are experiences that combine the best of the web and the best of the apps.”
- 7. Mobile web apps High user reach Low user engage Native Mobile Apps High user engage Low user reach PWA High user engage High user reach
- 8. How are PWAs different? Leverages the web's low friction. Delivers app-like user experience. Uses modern web capabilities. From pages in browser tabs to immersive apps.
- 9. Add to homescreen – web pages to apps Create a static web app manifest file. • Background colour • Display mode • Description etc..
- 10. Application icon set and rendered in a standalone mode.
- 12. “In a consumer mobile app, every step you make a user perform before they get value out of your app will cost you 20% of users.” - Gabor Cselle— Google Leverages low friction of the web?
- 14. Why PWAs, you wonder? Use and install instead of Install and use.
- 15. Progressive Web Apps Progressive App-like Add to Home Screen Linkable Discoverable
- 16. Progressive Web Apps Re-engagable Responsive Connectivity independent Safe
- 17. Service Workers The backbone of PWA
- 18. Service Workers “Service worker is a persistent, fully asynchronous, separately threaded event based worker with the ability to intercept network requests and cache responses.”
- 19. How does a service worker.. work? “Think of your web requests as planes taking off. A Service Worker is the air traffic controller that routes the requests. It can load from the network or even off the cache.” - Jeff Posnick, Google
- 20. Let’s recap.. • JavaScript file • Proxy servers in between the web app & the browser • Runs in the background, on a different thread • No direct DOM access - isn’t able to modify elements in the web page • Fully asynchronous • Works strictly with HTTPs • Cannot be used in private browsing mode.
- 21. Lifecycle of a Service Worker Register Install Activate
- 22. Registration Installation Activation Idle Fetch/Push message Terminated New Service worker Updated service worker Old Service worker still being used? Activates to become active worker Worker in waiting
- 23. Registering a Service Worker #code
- 24. Installing a Service Worker
- 25. #code – on install
- 26. Activate a Service Worker
- 27. #code – on activate
- 28. # Offline experiences How & when to use the cache?
- 30. General idea
- 31. Cache falling back to network – improving performance
- 32. Generic fallback – offline
- 33. #code – generic fallback
- 35. What is push? “The delivery of information from application server to the user in the form of a pop-up message or an alert when the client has opted for receiving certain timely updates from applications”
- 36. Why push matters? ENGAGEMENT RETENTION PERMISSION BASED TIMELY UPDATES NO FORCED COMMITMENTS RELEVANT INFORMATION
- 38. SAFETY FIRST – HTTPS ONLY!
- 39. Push workflow components: Client + Service Worker subscribes to receiving push messages (1) & eventually handles the notification (4). App Server initiates the delivery of a notification. Push Service a system for processing messages routing them to the correct clients. Service workers CLIENT Application Server Push service 1. 2. 3. 4.
- 40. Wait, WHAT?! 1. Draw some circles. 2. Draw rest of the owl.
- 41. What makes push notifications? “push” action of the server supplying message information to a service worker “notification” the action of the service worker sending the information to a user. Push API Notification API
- 42. # Subscribing Subscribe user to push messaging: Get permission from user to send them push message Subscribe to the push service. Get a subscription object = endpoint URL + client public key Send the subscription object to the server. Stored at the server, used when push message needs to be sent.
- 43. # Subscription object Subscription object = endpoint URL + client public key
- 44. # Send a push message - from server to push service Server generates the push message. Encrypts the message with client’s public key Sends the data to the endpoint URL on the push service. Push service routes the message to the service worker associated with the endpoint URL.
- 45. # Push Event Push service routes the message to the correct client associated with the unique endpoint URL Service Worker is woken up & Push Event is trigger Event listener to the Push Event handles the notification display
- 48. Don’t be too push-y!
- 51. Mozilla Service Workers Cookbook https://serviceworke.rs/
Editor's Notes
- Pwa, how they are diff from, what tech lies at the core of PWA & hw it all works out so seamless Great time to be building smthn fr the web
- Gem part of Moz India community I stand here to talk abt smthn that’s close nt only to mozilla
- 2 platform, how do you decide which one to go with? Yes the long old discussion btw the web & the native & 1000s or statistics & comparison data if only all decisions were as easy as this, but unfortunately they’re not, so where that leave us
- Flora & fauna Combine? The best of web & native to come up with app that leverages web’s low friction & at the same time Well that’s exactly what PWAs do
- Now why is that even imp? Well, generally talking, the use case dev app may vary from product to product but more users – two para
- Think about a situation when you need some information quickly. The answer is in your mobile phone’s browser. You find most of the information from web sites. And it’s less likely to search for a native App for that. We can see that, the web reaches more than 2 times as many people. This is mainly because there’s a barrier before using a native App.
- So that’s all great, what are really are PWAs?
- Prg web app, or PWA is a termed coined in 2015 by Alx Russel from google idea is in addition, PWA uses modern web capabilities, to deliver an app-like user experience. They evolve from pages in browser tabs to immersive, top-level apps, leveraging the web's low friction.
- is a simple JSON file that gives you, the developer, the ability to control how your app appears to the user in the areas that they would expect to see apps (for example the mobile home screen), direct what the user can launch and, more importantly, how they can launch it. In Firefox -
- And honestly its so much better, The “get the app” or “open in app” interstitials which would ask us to dwnld their app before we can continue browsing thru? Well, how about no? Why can’t we use a really well built mobile site? They feel lighter and sometimes you just want to follow a link n get out of there. Welcome, PWA! Btw, G+ found their "download our app" interstitial caused 69% of users to abandon, rather than dl app or continue on site. So they’d vouch for that being a terrible idea. G+ dropped theirs once they saw the data.
- So we’ve been talking about leveraging the low friction of the web Each step to download an app reduce 20% of users. PWA reduces the steps between discovery of an app and getting it on the home screen and there by eliminating friction of getting an app installed. This provides a very fertile ground for businesses to pitch in their PWA.
- Where the native app installation flow looks something like this, in case of PWAs you just click a url & use the app!
- So why not use the app & install instead of installing it and then using it? Now to sum up what PWAs are there’s a list of features that the app must support.
- P- basic content & func of the modern web app works for every user, regardless of BC or bandwidth, while at the same time prov enhanced version of the app to those with more modern web browser. A-coz built using app shell model. Basic app interface or the shell L-means no app store req, no complex installation process, u can simply link an app to a specific url. D-identifiable by brow/search engines as “app”
- R- supports features like web push which can be used to deliver push noti to users even when they are not using the app. CI- enhanced with the support of SW, they can work offline or on low quality networks S-PWAs are strictly served over https, which means they’re save, prevent snooping and ensures that the data hasn’t been tampered with. When we talk about being https, main reason-SW. Amazing features made possible coz of SW.
- To begin with, SW are simple worker scripts that run in the bg and they come with the ability to do two things best, intercept network request and cache responses. So what exactly are SW?
- SW is a persistent, fully async separately thread, event based worker. P- lives outside the browser tabs, knows when to expire. ST- similar to web workers, they do not die when the tab is closed, they run in the bg, in their own global script context. FA-they make heavy use of promises, hence are non-blocking EB- they do not have any direct control from the main thread, they respond to events like install, act, fetch push sync
- SW essentially act as client-side proxy servers that sit between the app and the browser. It takes the form of a JS file and can control the web pages it is associated with, by intercepting & modifying navigation & resource requests, giving you control of how app behaves. As ATC, when the web req are the planes taking off. As an ATC, SW gives you control over each & every web req made form your site. In the same way ATC may redirect a plane to another airport or even delay a landing, SW enables you to redirect your req or even stop them completely.
- Using SW you can hijack connections, fabricate & filter responses, while you may do it for good reasons, To avoid this, you can only register SW on pages served over https. Github pages are served over https so they’re a great place to host demos.
- Once you register a SW to your browser, there can be two cases. However if it’s an updated Sw, which is found by bytewise comparison with existing SW, in that case it is downloaded but not made active until all pages ass with the old SW are closed. Coz for a given scope, only 1 SW can be active at a time. A- sits idle until it receives a network req in which case it loads subsequent pages // when not in use, terminate to save mem
- This code starts by checking for browser support by examining navigator.serviceWorker. The service worker is then registered with navigator.serviceWorker.register, which returns a promise that resolves when the service worker has been successfully registered. The scope of the service worker is then logged with registration.scope. The scope of the service worker determines which files the service worker controls, in other words, from which path the service worker will intercept requests. The default scope is the location of the service worker file, and extends to all directories below.
- This is where we cache all the needed resources. When we are on network we can cache the data which can be used to provide offline access to resources when there is no network.
- caches.open and cache.addAll are async operations and the service worker could terminate before these operations are completed. e.waitUntil asks the service worker to wait while the promise is resolved/rejected. When the cache is opened, we try to add the assets to the cache with addAll Keep in mind that if any of the files fail to be cached (may because it's probably missing), the service worker will fail to install.
- Once your Sw is ready to control the clients & handle functional events like push & sync, we get an activate event. This is the ideal place to do all the things which we couldn’t do while the old sw was still in use, such as migrating database & clearing cache.
- In this event listener associated with the activate event, we’re just filtering the cache using the cache name and deleting the resources stored in it. This ability to cache files using services is what forms the background of providing offline first experience in PWAs.
- As you might know
- FlipKart is one of India's largest online shops. They created a progressive web app, Flipkart Lite that resulted in a 70% increase in conversions.
- This can be used for achieving two things, improving performance + providing offline first exp
- It “gets its name from its ability to push information to a user instead of waiting for the user to make a request.“ Since they use SW that run in the background, these notifications can be "pushed" from the server to the user even when the app is not running. So the noti that we generally get from native apps on our mobile devices, is what is now possible with browsers as well.
- They can do simple things, such as alert the user to an important event, display an icon and a small piece of text that the user can then click to open up your site. They help re-engaging and eventually retaining users at your sites. They are strictly permission based which means you cannot send a noti until a user opts-in or subscribes to getting noti from your website. They deliver timely updates with relevant information which the user might want to receive.
- Also the beauty of this is that there are no forced commitments from the user’s side in the sense that they do not have to share any contact information like email id or anything to receive notifications. The messages are simply routed to the capability url associated with the SW at their page. And of course, if the user wishes he could opt-out of receiving noti anytime they want to.
- Now, coz push tech is making use of SW, this is again done over https only. So we have a server that.. , a client that.., and a push service that sits in between them. Now, being https only ensures that the communication channel b/w..
- So this would be an over simplified diagram of how things work. The client registers for push noti with the push service. Sends the identifier to the app server. Whenever there’s a new msg, the server sends the msg to the push service at the identifier url and the push service finally routes it to the correct client who had subscribed to it at the particular url. If any of what I said in the last 30 seconds seemed like a verbal rep of this
- Push API is envoked when a server supplies information to a SW & allows a SW to handle Push Messages from a server, even while the app is not active. Notification API lets the app display system notifications to the user
- First the client subscribes to push services by clicking the allow noti button that pops up when you browse a website. This is basically the user saying hey website I want noti from you. The push subs has an associated unique url for each subscription. This endpt url + client public key forms the subs object. The client then forwards this to the app server which is stored in the database and used when a noti is to be sent.
- At the server side, whenever there’s a new msg to be sent, the server generates a push msg Encrypts it with the user public key Send the msg to the endpoint URL with a payload of encrypted data. Remember the push service cannot actually read the msg since its encrypted. It only routes it to the SW or the client associated with that particular url.
- Coming back to the client side, when SW receives the msg, push event is triggered It wakes up and executes the listener associated with the push event. This is where we handle the displaying of the noti at the client’s side using the noti API
- This is done something like this. You add an event listener to the push event, and can manage a bunch of stuff under that. And that’s it! This completes the cycle and you get a realtime web push noti from an app server to the client via SW!
- Now even though I can point out a lot of statistics that proves that PN effectively re-engage users and retain a substantial number of them on the website, the still are like a double edged sword. And can be prove to be really destructive in some cases.
- And that’s a wrap! So these were a few things to show what PWAs can do. If any of this has caught your interest and you’d like to get some inspiration to get started, you should definitely check out these websites.
- Which shows incredible amount of improvement
- If the tech resonates with the work you’re doing or if you’d want to play around with what all service workers can do for you, I’d highly recommend this amazing compilation of feature wise code for SW, so do check out the service cookbook it’s a great place to start.
- And if you’re wondering what all a service worker is currently capable of doing on a particular browser, do check out this website. So these were a few things PWAs can do, use sw max benef of web. It’s undoubtedly one of the best things to have hppnd to the web lately & we are