 So let's start. I guess Jason was still looking for some people. I think Jason is looking out in the hallway for if anyone else is standing outside, want to comment. But we can quickly start with introductions in the meanwhile. So we'll start with who we are. So basically myself, Saqeed Kumar, I work as a UI UX lead at QD42. His Piyush, he works as a technical architect at QD42. So basically today we'll be talking about, today's session is more about, we'll be talking about modern advancements in the mobile web. And diving into one of its major feature service workers. Talking about how to use them in your site and making your website more appy, more like a mobile app, and then with all kinds of tools, debug it. Followed with a small demo. So firstly, starting with mobile web versus mobile app. I'll start with a use case here. Like you have a scenario where you are in the scenario, you have to book a ticket and you don't have any mobile application with you. So what would be your preference about, will you go and download some application and download the application to book the ticket, or you'll just go to the mobile site of that ticketing agency and book the ticket. I guess, because downloading a mobile app would take you like a lot of time, a lot of mobile data as well. Let's say any app would be around 10 MB or something. So it would take time to download the app. So what would your preference be? Would you like directly go to the website and book a ticket. Given the UI is same in both the cases. You have the same UI on the app and same UI on the web. Which one would you go for? Even the stats is the same thing. Out of 7 out of 10 people will go for the mobile web and only 3 out of 10 will go for the downloading the application and then go for the ticketing. But when we see the stats from... So when we see the stats from the app stores, like this does start from Google App Store and it says more and more application being developed. And similar is the case with the Apple App Store. We can clearly see more and more applications being developed. So people rather than focusing on developing mobile-friendly web rather than making a mobile-friendly web, they are going and developing applications more. So can you think of why this is happening? Any reasons? Experience hasn't worked. I can have a better view of it in the mobile web as well. Make your site more responsive and... That's one good reason. Your apps would work offline as well, but I would not. So yeah, we can speculate a few reasons for that. Like the product owners or the developers, they don't want users to have the tabbed experience and in their application, they can do that clearly. But for mobile web, they will have this tabbed experience. And then, again, offline enable the mobile apps. Enable you to have offline data on your devices. But then again, this web, if we are relying on web, that won't be the case. Then if you think of the push notifications, which we don't have for the web, but for applications, we can clearly have this. We can update your users on the basis of any update in the application. Push notification or simple notification. Also, you have this splash screen, which is a good way of branding of your product. So these are the... And there are many more reasons. Like you have more access to this performance and then like... I think low-level hardware will be one thing. So you don't have access to hardware by any means. Yeah. In 2010, this... Wyatt published this blog about when the app world was growing, stating that web is dead, as mobile applications were the future for all... with all these new features, which mobile web did not have had. But again, later in 2014, seeing the trends which users were following, which users were using, even for... users were more like... where traffic was more on web. So then again, they came up with this trend, as even the features were great for mobile apps. They had some overhead of downloading that application to have that experience. So users were forced to download their application from the app store to the mobile and then have that experience. So downloading and install was an overhead. So still users prefer mobile web over the app, at least as per the data which we saw earlier. So progressive web apps are the new way of strategies to develop your web app mobile-friendly. We can take an example of Flipkart, an Indian e-commerce company, which was among the first adopters of this. They had mobile applications for the product, but they still found out that the traffic was more for mobile web. And even more than their desktop website. So to enhance the user experience for their users, clearly if you go to a mobile web and then if you give a pop-up to go to app store and download the application, that's not a good UX. So to enhance the user experience, they adopted this strategy of progressive web apps and they released flipkartlight.com which is clearly similar to their mobile app. So for this, the users don't have to go and then download Flipkart from the app store. They're just going to go to flipkartlight.com and they'll have this experience which is responsive, which works faster, even the network is bad. This works fine for networks like 2G or Edge and has features like push notifications, splash screens. So to get the mobile experience for Flipkart again, you don't have to download these. You just need to go to flipkart.com So in this talk, we are not going in detail with progressive web apps. We are just diving into one browser feature, Service Focus, which would enable us to have features like offline content, push notification etc. So before anything, I'd like to play this video. So I think this case would have happened with almost everyone, right? Like stuck up on a loading screen, waiting for it to load, load, load, right? So yeah, Service Workers would help you eliminate that or at least enhance this experience in some way. We'll take a look at that in details. So Service Workers are basically a browser feature which has recently been added and then work is still in progress. Currently, latest browsers like Chrome and Firefox they support it but still there are things to come in. So basically it's a worker thread working parallelly to the network thread. So you don't have access to the DOM. So I'll talk about the features. So it has features like offline web and it enables your website to be functional in case of low connections, even like Edge and 2G which we talked earlier and then it gives you a programmable cache. So earlier we had this app cache but that was very limited. Its functionality was quite limited and it was static but here you can now have a full control over the cache and you can script your cache. Then you have this background processing like you can have some tasks running in the background like you can sync user's activity later on or show the functionality like geofunction, push notifications and geofencing. So these are the features. But with every great responsibility with every new power you have a great responsibility like in here service workers are only available with STTPS networks because service workers lie between your user or the client side and then the server. So if anybody having the access to service worker can easily intercept your network request. So it's again then since STTPS is not an encrypted thing so it is only available with STTPS so that any transfer data transfer is encrypted. So the pillar of service worker it has a scoping, you are a scoping so we need to mention the scope of the service worker where it had to pick all the resources and then document matching and then it runs on same origin and then it has a separate thread of execution and has no DOM access. So now we'll dive into how to work with service workers and then I think you should take on. Hi guys. So till now we have covered like what service workers can do for you. We haven't seen how it works and how would you actually write code that would allow your browsers to intercept your network request and everything. We'll dive into those now. So starting with the life cycle of a service worker so what are the phases in the life cycle of a service worker? So initially when your web page loads it doesn't have anything like service worker installed on it by itself. So the first thing that happens is your service worker goes into an installing state. So installing is something wherein you would ideally go ahead and pre-cache something. So let's say you have your website and it has a couple of static resources like your CSS files, your JavaScript files something that could be called as an application shell something that a user would see as a skeleton. So how many of you have used Facebook applications? I think everyone would have used it. So when you open it, instantly what you see you don't see any data, you see a loading you don't see a blank screen, instead you see placeholders and you see the header. So that's called as your application shell something which is your skeleton application without any data. So pull out your data from your application and pull out the skeleton. So skeleton is something that you would pre-cache. So that's something that you will do in the installation step. So once a service worker is installed it could go into either of two states either it could go into an error state or it could activate. An error would happen in case it failed to cache a resource or something returned a 500 error one of the resources that returns a 500 error or you're not an HTTPS at all it would return a, it would go into the error state and then doing a browser refresh would restart the installation state. So far good. Once it goes into the activate state so that's where the service worker would take control of your website. So till it reaches the activate state a service worker is dysfunctional on your website. Activation is a state wherein you do a couple of other things as well. So for example you have service worker version one running. You had a couple of things which you cached earlier. Now you made a couple of updates to your website. Now let's say you added one more CSS file and one more JavaScript file. You would want them to be pre-cached as well. So that's something that you would do inside your activate event. So activate is something that acts as a place where you could clean up your cache you could rebuild your cache. Those sort of things. Because activation is something right after which service worker would take control of your website. Make sense? After going into activate state it would ideally go into idle state if nothing is happening. If you do a fetch request go into the fetch state and return back to idle after doing its processing or it could just terminate once it's done with its job. Okay? Moving on to the next slide. It's a very simple slide which talks about how connectivity could affect your web app. So in the case of good connectivity it's a simple network fetch and a normal response which you just see on the browsers. But in case of a bad or slow network connection the network fetch would happen but it would lead to ideally a timeout or a DNS look of failure, right? Which is a bad UX. The user would again be stuck with a loading screen and doing nothing. So let's see how service worker would save the day for users. So service workers are something that sits between your web page and your web server, okay? So any request which is going from your web page to the web server would pass through the service worker. You see, this is where it becomes... So as Hake talked about it should run only on HTTPS. That's a specification because it could control any and every request which is passing from your web page to the web server. So let's say you have an e-commerce website users fill in their credentials, their credit card details and if a hacker gets control of the service worker they could intercept all of these details and reuse them. With HTTPS all of this data would be encrypted and would be of no use to the hacker, right? So yeah, let's take a look at this flow diagram. The request, so let's consider fetch request which is happening for some URL. Service worker would first of all intercept it. It would look for this data, for this fetch request in the cache, in the browser cache. If it finds it, it would return a promise object which will pass back to the web page, the browser. So in this case there's no head to the server at all. So even if you're offline, you would be able to see some response, right? In case it doesn't find it, so with... How many of you are familiar with JavaScript promises? Okay, cool. So yeah, with promises it could either resolve or it could reject. In case of reject, you can program your service worker to look for this, to perform another fetch request for this URL to the network. Now the request goes to the server and the response is sent back from the server to the web page in this case. So it works both the ways. Even if you're offline, the user is able to see the data. Even if he's online, he sees the fresh data. So yeah, we'll be diving into the code base now. Let's see how service workers would actually work. How would you actually register a service worker or how would service workers take control? What code is responsible for that? So in the right side bar, you see the code that says if service worker is a navigator. So navigator is a browser object provided by browsers. Now if your browser supports service workers, it would have the service worker attribute in the navigation object. Otherwise it would not have that. So the very first thing is you should definitely check if your browser supports service workers or no. We'll take a look at the slide wherein we will talk about which browsers support service workers and which do not. So yeah, the first step is to check if your browser supports service worker or no. The second step is to register a worker. Now the second step is navigator.server.register. So you're registering a worker. Now your sw.js file is what is going to control your network request and everything. So all of the code related to your worker would go inside service worker.sw.js file. The second argument to this is an optional scope. So for service workers to work properly, it needs a scope. So it says that I will control all of the requests which fall under the scope. So if the scope is slashed, it's clearly going to control any and every request which is going to be there on your website. Let's say we put the scope as slash sw. It would control any request which starts with a path slash sw. And then again, it again is returning a promise. And if it resolves, it goes into the then function and if it rejects, it goes into the catch. So yeah, check for the browser support. Scope is defined by that. Now the second step, so the first step was registering a service worker. Over here we registered a service worker. We created a worker file. Now this worker file is registered with your scope slash for your current domain. So let's say our domain is nola.qld42.net. And we registered our service worker.js file on root scope. So what happens is any request which is going to be passed to the server will pass through the service worker.js file now. Now we talked about events, we talked about events that service worker does have, the install event, the activate event and other events. So if you need to do something on one event, you can attach a listener to that event, your custom listener. So as we talked earlier that service workers are completely programmable cache. So you could program it the way you want. So let's say we want to pre-cache a couple of resources on install event. So we would go ahead and add a listener to the install event and do a couple of operations inside it. So the first thing is install is basically used for pre-cache. App shell we already talked about. Before we go to the activate, you see the function over there which says event.waituntil. So service workers also provide you a way for your service worker to stay in a state until unless it has finished its job. So anything that's inside your event.waituntil until unless that completes, your service worker would not move from install to activate our error state. So you can basically say that pre-cache all my resources and then move to the next state. Okay? So that's where you would use event.waituntil. Activate function, activate event we already talked about it's mostly used for the cleanup of caches, cleaning up old cache. The next step and the most important one is intercepting your network requests. So service workers provide you with an API to do that. So you would again attach an event listener to your fetch event and do intercept your request, do whatever you want to do with that request whether you could return basically an empty hello world response even for any other pages by intercepting these requests. We'll take a look into how you should intercept requests or basic caching strategies which we have in place. Talking about basic caching strategies we're going to discuss only two of them today. The first one is offline first wherein all of your requests get served from an offline cache first and then it's looked up in the network. So that in the first time when you hit a web page you get a stale response in the background service worker would pull fresh data and update your cache. So basically the first request would give you a stale information but if you're online the next refresh would give you the latest information. So offline first I think we already talked about most of these. So it's mostly useful in case of single page apps or applications wherein you have data separate and your view layer separate. But yeah it works with Drupal as well. We have built a demo, a short demo. So offline first. So the very first thing that you do is you pre-cache you describe your resources which you want to pre-cache. So let's say in this use case we are defining a cache bucket which is called as decon-nuller and the static resources which we want to cache in this cache bucket. So it's always a good practice. It's always a good practice to have separate cache buckets for different kind of resources. So you could have both the caching strategies in a single service worker. Let's say you could have a cache bucket which is going to follow an offline first approach and another cache bucket which would follow your network first approach. So you define two cache buckets in that case define your static resources in one of the buckets and your dynamic resources into another bucket and initially pre-cache both of them but when you're writing your fetch event listener you describe two different ways of handling your both cache buckets. We'll take a look at how to do that as well. So yeah in this example what we are doing is we're defining a cache bucket, a couple of static resources and attaching another event listener to the install event and inside the install event we are using one of the APIs which is provided by service workers the cache API. So this would allow you to write data into your cache into your browser cache. So cache.addall what it does is it performs requests for all of the URLs in that array in the static resources array and cache them in the browser cache. So the first part is your app shell and event.wait until we'll wait until and unless your resources are cached. The second step would be processing your requests. So you add an event listener to your fetch event and there's again a function called event.respondwith. So this is again provided by your browsers and provided by service workers which is again provided by your browsers. So you could choose to respond with data which is pulled out from cache rather than from the network. So if you take a look at the function serve from cache what we are doing there is we are doing a caches.match for the current request URL. If a match is found we do return a response from here directly. The request doesn't even hit the server. And in case we don't find a response in this case we are just returning a redirecting users to an offline.html page. So again talking a little bit of the topic here but yeah when you talk about service workers the need for service worker would differ would vary per application. You would never have a same kind of implementation or a generic application for all of your applications. It would always vary. So in this case we are redirecting users to offline.html in some cases you would want to update the cache as we talked about. Update the cache in the background and present the users with the fresh data on next request. Another interesting cache strategy is serving from network first. So what we do here is we replace the function serve from cache with serve from network. In this case what we are doing is we are doing a fetch request on the request URL and we update the cache first and then send back the response. One interesting thing to note here is we are performing a clone on the response object. Can anyone take a guess why we are doing that? Why do we need to do that? Yeah, sort of similar thing. So it's a readable stream basically which could be consumed just once. So either you could respond back to the server or you could cache it. So to cache it we create a clone and just cache it into the browser and return back the actual response object. Make sense? And in case it fails, we are going to do a lookup in the cache and present users with a stale copy of the page. So are you guys able to visualize what I'm saying? I know it's difficult just by reading the code, but yeah, if you have got any other custom scenario or handling the cache first thing which is very, very important in case of service workers, you need to be very specific when you need to basically enviromate your caches. You need to be very, very clear about that when you want to do that. And it again depends on your application needs. It's not generic. But still there are a couple of utilities which are available right now which allows you to burst caches. So for all of you service workers it's completely flexible and it's programmable cache. So go ahead, code your own logic for bursting the cache or handling your own custom caching scenario. Another important aspect of service worker is how or when, how do you update it? So your service worker is running. So Sakit already talked about service workers as separate thread, right? Now what he meant by a separate thread was your web pages would load but service workers would run in parallel. It has nothing, it has no control over your DOM. It cannot do the DOM manipulation. It doesn't have the power to do that. It's running separately from your website. So that's one of the good reasons it could do the background processing. Even if your website is not running your service worker could be running. You get the idea? So even if you don't have your tabs for your websites open, service worker could still work in the background and perform jobs. Now the tedious thing is how to update these things. Like this is once installed in your browser. Now how would you update it? Because a lot of users are already running these service workers on their mobile apps, on their web apps, right? So service workers do provide you with a way to do that as well. Let's consider a use case wherein we are going to split our cache into two parts. We're going to split our cache into JavaScript resources and CSS resources here. So the first step would be you update your service worker code base. And once you update your service worker code base and it loads on the browser, the browser would automatically detect that there's a change in this file and it needs reload, okay? And if the check succeeds, I mean if the service worker is a new file, if there's a difference between the... even a byte of difference is there in the size of the file, it would fire install event for the service worker again. Now the interesting part is here, once the install event is fired, the service workers would go into waiting state. Now what waiting state means here is they would not install, they would not update your cache buckets or update your caches or delete or do any operation on your caches. Now it would wait until or unless all the instances of your service workers, previous service worker versions are closed. Because there are other tabs, there could be other tabs on your browser which are open, which are being controlled by the previous service worker and you would never want a user to land into a scenario where he sees an inconsistency, like one of the tabs is behaving another way and another tab is behaving another way. You would never want that, right? So service worker would go into a waiting state and stay into the waiting state until or unless all the current versions of your service worker are closed. So once they're closed, the first refresh of the page would trigger the install event again and then it would go into the activate state. And activate is where you will hook in and again basically do your cache processing, cache bursting. You delete your, purge your old cache, right? So that's where you'll do all the things. One of the overheads over here is the browser checking for your service worker.js file on every request. So you could again control this using your HTTP cache headers. So you could set a max age for this file and it would not be checked for that duration. Updating service workers. So yeah, this is the code example. So what you're doing here is we're creating two different buckets, JS bucket and CSS bucket. One of the resources does, one of the buckets would hold the CSS resources and another one would hold the JS resources. Yeah. So you update your service worker.js file which was the first step. You update your install event and you basically now create two different buckets and cache data in the two different buckets for your CSS and JS files. And the next step is activate. So in activate what you're doing is you're going to create a white list of your caches. So basically this is the logic which we have done. You need not follow the same logic. What we're doing here is we are busting the old cache. We are deleting the old cache buckets. We're deleting all the cache buckets apart from JS bucket and CSS bucket. You would not want to have browser holding the old cache data. And one interesting thing here, suppose you want browsers to take control of your service worker which is getting installed currently. You want it to happen instantly even though other tabs are there which are open which are being controlled by the previous service worker. So in that case, service workers provide you with an API to do that using event.replace function. So you could just call event.replace function inside your event install event and service workers would go into activate state rather than going into the waiting state. Browser support, so Chrome 40 plus, Opera 27 plus, Firefox 44 plus. Safari, the support has come for the mobile browser but it's not in yet for the web browser. Sorry, desktop browser. It's not in there yet, I think. And you can always check the browser support at the URL mentioned below. Now there are also cases, there are also APIs for which there are polyfills which are available. So polyfills are nothing but small JavaScript libraries which you could inject to add additional functionalities for a website which is not supported by a browser. So there are polyfills which are available to do that as well. That's again available at the same URL as service worker ready by Jay Kakabal. Tools and tooling and debugging. So obviously when working with service workers you would have, it's a pain to debug service workers which I have experienced in like last week while I was preparing the demo. So yeah, there are a couple of tools which we came across. The very first one is the Chrome dashboard which allows you to see all the service workers which are installed on your browser currently. So you could go to Chrome, service worker internals. It would show you a list of all the service workers which are installed on your browser. You could emulate your events from here right away. So you could either unregister the service worker from here or you could start the service worker and perform your push notifications, perform your fetch operations right from here. You don't even need to open the website for that. This is the power of service workers being running in a separate thread. Local development, it's a pain. If you don't have an SSL certificate you cannot work with service workers. With Google Chrome, you could treat insecure origin as a secure origin using this command above. Network request, so any network request which is going through a service worker would have the size column saying that it's coming from service worker. Chrome DevTools is again a good place to do your debugging. If you open your DevTools for a page which is controlled by a service worker there would be a service worker which you could inspect in the service worker tab. Again, you could add breakpoints and when your service worker runs it would show you a stack of variables and everything. The code which we saw right now, the examples which we saw right now it included a lot of code to do very simple, simple stuff. There's a library called as Service Worker Toolbox. Let's take a look at the third example. All the code says it's toolbox.trouter.get slash all the requests, basically slash asterisk it means all of the requests. For all of the requests global.toolbox.cachefirst use the cachefirst strategy. In order to do an offline first application all you need to do is just write this piece of code and include the Service Worker Toolbox library rather than doing all of those number jumbus which we did. There are two common use cases which we came across while preparing the demo. By default, your service workers would go ahead and fetch an anonymous response. It would not send the cookie back in the request. So there's a flag which you could set credentials to. If you send a request with credentials to your cookie will be sent along with the request headers and you'll receive a authenticated response. If you need to cache cross-origin request you could pass it another flag called mode. Now mode by default it's set to course. So it respects the cross-origin request sharing principles. But you could set it to no course and it would still fetch a response for you from a different origin. The only difference here would be it would be an opaque response. By an opaque response I mean that the response that status you would never get to know if it succeeded. But if it passes you will have the data and the cache. So the demo, quickly talking about the demo what we're going to do here. So we were building a camp website for Drupal Camp Pune and we were also experimenting with service workers so we thought why not give users an offline experience. Users were demanding for an app. So we were like let's build a mobile web app rather than building mobile apps. So we experimented with service workers and we allow the users to access the website offline right now providing an app like experience. The users can add schedule to their... can use the add to schedule feature even though they're offline. So what happens is when they're offline they hit add to schedule. The data gets stored in the index TV of the browser. When they get offline this data gets synced back and the user receives a notification on his cell phone that your session preference has been synced successfully. Drupal enhancement which we had to do. There were a couple of routes which we had to build. The very first one was... the very first problem for us was to fetch the... to pre-cache the aggregated CSS and JavaScript files. Because in Drupal we cannot fetch the... we do not have a direct way to get the name of the service... get the name of the CSS and JavaScript aggregated files. Those are like random hashes generated, right? That was one of the problems. So we created a new route in Drupal 8 to do that. The second one was... so we were using flags for add to schedule feature and we had to write a custom route to handle the... backgrounds and corporations because the data need to be... posted back to the Drupal server. The third thing was caching the session and sponsoring URLs. So there was no direct way we had to... we had forgetting the list of nodes, the node IDs. So we created two different views with REST export format and session.json and responses.json which we were... returning as the JSON objects. Hook page attachment alters, hook page attachments alter to include the service worker JS file and manifest.json. So we also integrated the progressive web app... concept into this. Cache strategies which have been implemented are... offline first, network first, slow connections. In case of slow connections, the offline first kicks in and it again works well. And there's an offline page which redirects. So I'll quickly go through the demo. I don't think we have much of the time left, but yeah. Let me just quickly... So... Sorry? Slides? Slides are public. Yes, slides are public. This one? No, no, this side is public. Yeah, yeah, yeah. Yeah, I'll share the URL as well. It's... I'm not very sure if Internet is working well. Let me quickly open that. So yeah. If you could browse this webpage from your cell phone on an Android Chrome browser, it would look much better compared to the demo that I show you here. So yeah. Let's take a look at the service worker which is... Let me actually mirror my display. So I'm actually going to de-register the service worker which is in action right now and purge all the cache which is creating. There's an index to AB. Okay, cool. So I'll hit refresh. So the first refresh, it's going to now register my service worker. Do nothing else. The service workers are not taking control of your website right now. The next refresh would make service workers take control of your website. Whoops. So see, it stopped because there's another tab which is open which is being controlled by my previous service worker. So I'll need to close this tab first. And then... Re-register it. So you saw the switch, the switch from installing to the active state. So yeah, it goes into the installing state and then into the active state. And in the meanwhile, our cache. So these are the sources which we are pre-caching. There's some dynamic web URLs which we are pre-caching which is your node IDs for your session pages and your sponsored detail pages. The assets are your CSS and JavaScript files which are your aggregated CSS and JavaScript files which are getting loaded on this website. So they have been cached as well. So this is what a normal user will see when he's online. Let me see if I'm logged in. Yeah, I'm logged in as PO 23. Now let's say we go offline. Okay? We're offline, the flag says it's offline. So yeah, let's do a refresh. The page still works. The images are not getting loaded and that's why they are replaced with a static background image which I'm doing. This is something again which we're handling by our service workers. Let's browse through the website a little bit. Go to sessions. This is a list of sessions. Sponsors, it works fine. About page, when you... When you... My Schedule, we haven't cached this page. So My Schedule doesn't appear. But at the same time, we're caching My Schedule page when a user hits it for the first time. So let's go online and hit My Schedule now. Okay? Now we go back offline. The My Schedule page works. Right? Another interesting thing to note here is what we did was when you're online and you go to the sessions page, the Active Schedule feature, it works the way it should, using flags. Okay? And you see the button is green. As soon as you go offline, these buttons would turn gray telling a user that you're offline right now. You could basically add it to your schedule but the data would get synced back only once you get back online. Okay? So let's try adding another item to our Schedule. Oops, sorry. It's in the slide. It's N-O-L-A dot Q-E-D 42 dot net. Use S-T-T-P-S. Yeah. So as soon as you click on Add to Schedule, you see this pop-up which uses the Chrome API. It's asking for... It's asking you if your Chrome should be able to send you notifications or no. If you allow, the data, it gets stored in your index DB. So yeah. The session ID, the user ID and the action it should perform. These, this data, it gets stored in your index DB for the time you're offline. As soon as you go back online, this data will get synced back. Hold on. Come on. Okay. Finally, we went online and you see this notification. We got the notification that your preference for your sessions has synced successfully. This data gets purged out from your index DB and now if you go ahead and visit your My Schedule page, you should ideally see this session in your sessions list. Yeah. There we go. So yeah. This example... I would have loved to do a code walkthrough as well, but I don't think we have much of time left. But yeah. Going back to the slides. Oh yeah. One more interesting thing. So since we couldn't do the demo on the phone, we recorded the implementation of PWA with the application as well. So the user logs in by the browser. He can choose to add this item to the home screen. This is what installable web app means in terms of PWA. So as soon as he added it to the home screen, it gets installed like a normal mobile application. When you hit it and when you try to browse it, if someone who doesn't know Drupal, they would definitely say that it's a native app. It's not a mobile app. So I've tried this with a couple of my colleagues and they were like, you built an app for the Drupal Campoone? So yeah. You can browse through the... Is it stuck? No. So yeah. You can browse through the website like a native app right now. Yeah. This is the home page. Let's go to the sessions page. Now you see the same buttons over here. Now you go offline and try adding something to your schedule. The Chrome will ask you here as well if you want to allow users to receive notifications or no. Next step would be you go online. As soon as you go online, you'll see a notification appearing on your phone which says that your preference has been synced successfully. And then you browse to your My Schedule page. And then you'll see the session it appears in your My Schedule page. So yeah. That was about the demo. Moving back. What happened to this? Okay. So yeah. The resources that we used for preparing the slides are down below. If you want to try it for yourself, go to browse.url. The code base it's available at in the GitHub repo down below. If you want to read more about service workers, these are a couple of URLs which you could always refer to. And any questions that you guys have? Yeah. If you're doing an offline app like the one you just showed, would you recommend caching full HTML pages for the 20 sessions, 50 sessions, or making each of those a rest request? Rest request, I would say. Okay. Your site is going to not... And the question I have is if you preload the whole page, then your site will still work even without JavaScript. You just won't get service worker integration and so forth. If you make it rest requests, then your site is only going to work with JavaScript. You've got a lot more JavaScript on the client side, but you're downloading a third as much data or less. So how do you decide what trade-off to make there? Yeah. So that's the reason I said that I would personally go for rest endpoints. So pulling out the data. So this way it makes my life very easy. I can separate out the app shell and I can separate out the data. So a user would initially see an app shell, a header and probably a Jeff animation. But as soon as the data loads in, I populate them. Apart from that, I could do a lot more as well when I use rest endpoints. Like doing background sync becomes very easy. So let's say a user is browsing this web page on a slow connection and there's a new item which has been added. Now, pulling only one new node, pulling a couple of data related to just one node is relatively simpler for me compared to pulling out the entire listing page. Right? Okay. And then the demo site you're just showing, is that built on Triple 8 then? Yeah. Sweet. Thank you. Any other questions? Okay. If ServiceWork is running in the browser on the mobile, what happens if you are offline, do something close the browser? Would the notification still get through? Yeah. So the notification runs regardless of whether the browser's running? Exactly. Okay. Because ServiceWorks are a separate thread from your browser. Any other questions? BigBipe is entirely a different domain compared to ServiceWorkers. Yeah. Yeah, so the way I would see is BigBipe working along with ServiceWorkers would like really pump up a website to what extent I can't even imagine. Okay. What I heard about caching, what can ServiceWorkers do besides the caching? Let's say I have a mobile, I have a code for mobile using JavaScript, and when the cell phone screen gets off, that it doesn't work. Right. It's JavaScript. Can we make it work using ServiceWorkers? I didn't fully get your question, actually. So basically you're saying that when your mobile screen is off, your JavaScript doesn't work. But would ServiceWorker work? Is that your question? Yeah. Yes. Let's say I have a code that every 10 seconds checks with the server using JavaScript, but when the script gets off on mobile, let's say Android stops it. No. So it depends on what you're doing with the JavaScript. If you're doing some DOM manipulation, that's not possible with ServiceWorkers because ServiceWorkers doesn't control your document. So let's say, let's consider one of the use cases which... So I need a pull request. ServiceWorkers cannot do it. Yeah, it can do the pull. It can do a network pull. It can do a network pull in the background, even if your screen is off. Okay, that's good. Yeah. There's one interesting use case, by the way, with ServiceWorkers, which I was again planning to demo, but... So how many of you know about geofencing? Right? So ServiceWorkers is a very interesting use case for websites which are going to display different data around different geographical locations. So as soon as you move from one place to another, ServiceWorkers would, in background, pull data according to that geographical location and present it with that data. So it's right on the move. So let's say if you divide this new audience into sectors, into geofence locations, let's say you put French Quarter in one of the fences and put Downtown in another fence, you move out of Downtown and you'll see a notification on your cell phone which says that you've moved out of Downtown and this is the data... The data would be refreshed, basically. Yeah. Thank you. Welcome. Any other questions? No? Thanks, guys. Feel free to evaluate our session and put your comments on the URL below. Thank you. Thank you so much for listening.