 So, we did a two-day program that was protected through mobile apps, like only with the knowledge of HTML, JavaScript, and CSS. Like, if you want to develop an app for iOS, you have to learn how to build your own Java product, right? So, if you want to state that this was, like, mobile developers, you have to come from the rules, that's kind of the story. So, what exactly we can talk about and about that. So, I'm here at SYNC. I'm here at SYNC with me as a senior software engineer at VPN. So, if you guys don't know about us, we have products like IPvase and VectorX. So, IPvase is, it provides a set of fewer components for different pages, like the first one, for the second one, for the third one. So, a similar tool, just like the Presbyterian one, so we got a competition here. And it basically, the difference here, what the Presbyterian is, it actually gives us the native code, but here it provides us the returns to design the files and the returns as the react native code. And this has a lot to do with that. So, what exactly the process is about this? Processing, like, the web app should go faster, it should be reliable. So, reliable in the SYNC, it should work, you know, on a story and connections for developers. Then there is no network connection at all. And plus, it should also support the specifications. So, I'm going to make a brief comparison between, like, native apps, traditional web apps and PwIs. So, for a similar question, what exactly is the PwIs? It's a hybrid of mobile app, I heard. So, there are some of the points for, I can't close in terms of the PwIs. So, obviously, you can have a higher performance. This is the permission, but you don't know to all the publishers, like what is similar to a PwIs. So, you just have to include that particular JSON file. This is an example for manager JSON. And then you have the properties you can define. So, that's not the same thing as traditional web apps. You do have notifications. But what happens is that when you close that particular app, the notification won't be shown. So, the threat is, the notification is traditional. So, there's something called a splat, right? Which is a splat, right? So, there's something called a splat. So, there's something called a splat. So, there's something called a splat. So, there's something called a splat. Which is a splat. So, what is the splat? It actually, it creates a public. It will send that data. Endpoint URL. Like, where exactly do we need to send that message? That particular part will be specified in Endpoint URL. So, it's available for both PwIs and JSON. It gives the graphic details. You just need to set GCM API. It will send that push notification. We have the Endpoint URL. So, it identifies the particular unique process. We do have a client side to receive a push notification. First of all, we need to subscribe to that. So, what happens? We subscribe, we push the data. We like push the subscription object. It identifies this particular unique process. And then we also have to make the request, right? First of all, we need to request permission for that particular page. So, here is an example for how exactly does this service work? So, what we are doing is we are adding an event listener for push service. Then the notification update will send that to an html file notification object. So, there won't be any difference. But the only difference is the normal traditional setup and the service local push notification is that even when your particular tab is closed, the notification will be shown in PWA. But that's not the same case in traditional PWA. But the probe thread should be running. What happens here is the event will wait. So, our self-taught registration show notification will return a promise and the event will wait until that particular notification is shown. One of the main features in PWA is offline. Here you have a web app which actually works offline without internet connection. So, that's quite huge for a web app. This is a web app and it is working offline. So, you will have maybe mobile apps which work offline. So, this is one of the main advantages in PWA. How exactly do we do it? First of all, let me go through the flow. So, what happens inside PWA is that service local access the network proxy. So, what happens is when a client creates a request, he goes through the service worker. And service worker will try to access that content from cache. If that particular content is available in cache, it will return that particular content from cache. Or that's if that cache is missing, then it will go through the network. So, what happens in offline is that if you have that particular content cached, so the service worker will directly access that content from cache. It will go through the network. So, that's how offline capability is supported in PWA. When should you update? So, since you have your caching abilities, how exactly do you update your PWA? So, you would have seen an update is available in the notification. So, what you should do in updating your PWA is that it should not interfere with the user exactly. So, you can just play a prong with one of the main important things in PWA that the cache won't be updated until and unless you close the tab. So, like if that particular tab is not closed, you can just play that user that the particular update is available and then you can click on that particular button to show that a particular update is available. So, that when you click on that, the particular cache will be request. So, that's how you handle updates and questions. We are talking about PWA in React Conference. So, React has some advantages if we use React while developing PWA. So, one of the main things I said was this. So, if your development has PWA, what happens is that you have a client-side JavaScript which will execute in browser and the Google won't be able to index them. So, React will provide a method in HTML string. So, if it returns in HTML string, when they call the meta tags, an item meta tags will be supported which will be supported by Facebook, Graphic PIs to better index it and even by Google. So, another example for like, I'll say reports of PWA should be they have coach-plating and lazy-doting in the fact which can be achieved through React also. So, here we have an HOC in React so what exactly are we going to do is we are creating multiple JS files instead of having one named out JS nullified. We'll be creating multiple JS files based on that particular component. So, until and unless, like, we will have some message for that user. So, the user won't be waiting for some content. We will have some coding message and with that particular content component is loaded. We'll have multiple JS files for smaller size but with that particular component PWA, so what about P bugging? So, Google has double both of these based on Lighthouse and Google. This is an example for Flux Drive, as you see, there's an SEO on all of them. So, that is our discoverability feature. Workbox is also provided by Google. Previously, Google had SWP, Cache and SWP box. So, in combined both of them this is an example of how exactly Google creates a particular content where you can even cache dynamic content, dynamic API responses, and even strategy messages through Workbox. So, these are the some of the strategies that we have cached on this work that access the content content from Cache and Cache was falling back to the network so if the cache fails, it will fall back to the network, Cache will fall back to the network update, Network 1 and then Network 1 is falling back to Cache so the network is there, it will try to access the network and if not, it will try to access Cache. It has been developed, why don't we try it? Even Apple has started supporting for service workbox and even Google has dedicated pro-labs in favor of PWAs even Windows 10 has started supporting for PWAs so why don't we make our web apps progressive in future? Thank you guys.