 Welcome to the Chrome Enterprise Technical Community Hour. Today, we'll be talking about multi-origin PWAs and the Scope Extension API. My name is Rich, and I'll be your host for today's presentation. Joining us today is Damien Renzuli, who's a partner engineer for Chrome Enterprise. For today's agenda, I'll start with a quick introduction of the Chrome Enterprise Recommended Program and the Technical Community Hour. After that, I'll hand it over to Damien and he'll cover PWAs and multi-origin sites, web app scope extensions, and building multiple PWAs on the same domain. Today's Chrome Technical Community Hour is brought to you by the Chrome Enterprise Recommended Program, which is Google's partner program for third-party solutions that are optimized for Chrome OS or integrated with Chrome browser. This webinar brings you the opportunity to engage their team about new features and updates, enterprise development best practices, and our enterprise strategy. Now, without further ado, I'll hand it over to Damien and he'll kick us off. Damien? Thank you, Rich. As Rich mentioned, today we're going to talk about a topic that we frequently see in many sites and in many companies that want to build progressive web apps. Unfortunately, in most cases, developers realize that this is a problem when they are halfway through in a project, so we have decided to treat this topic separately in this way. If you are not familiar with terms like progressive web apps or things like service workers, you can check out the playlist for Chrome Enterprise Developers where we have more content related to these topics. But even if you don't know much about these terms, but you have a site and at some point you are thinking on building a progressive web app, this might be also relevant for you. Let's start with the first case, which is that you have a site that consists on multiple origin, and you want to create a unified single PWA experience across all of these origins. Let's start with an example to visualize this more easily. You might have seen a lot of sites where the user starts the journey in the main origin, for example, the homepage, in this case, example.com, and as they navigate, they end up visiting different subdomains during a single session. Architectural decisions like this one often have important long-term implications on a PWA project. There are different reasons why many sites are built in this way. We can consider some of them as acceptable practices while others are actually not recommended. So let's start with the good or acceptable uses of multiple origins. The first one is a very common one that you might see across the web, which is localization. In this case, using a country code top-level domain to separate versions of your sites to be served in different countries. You might also have seen something like this that's subdomains to divide sites targeting to different locations, in the case you are showing it for different cities, but could be also for countries as well. And as we will see with this type of configurations, as long as the user doesn't move frequently across different origins, it's not a big problem. The second one is what we call independent web applications or independent PWAs. This basically means using different subdomains to build PWAs or web apps whose proposed differs considerably from each other and also from the site on the main origin. Here again, the user starts their journey in one origin or web app and usually stays there for the whole session, or at least doesn't move frequently back and forth. So we don't consider this as a bad practice. Actually, this is an important case where using subdomains can actually play to your advantage so that we will cover this separately at the end of this presentation. Finally, some developers separate common sections in subdomains. While this is not always a good practice, we can think of it as acceptable for some use cases. For example, if a company has multiple applications and all of them use the same login flow, it is not unusual to move this section to their own origin to centralize traffic instead of replicating this functionality in every single application. So as discussed, these examples can be considered good or acceptable practices. But if you're not doing any of these things, it's likely that using multi-origin site architecture will become a disadvantage when building a progressive web app. So let's take a look now at some examples of non-recommended uses of multiple origins. Common one is arbitrarily separating in multiple origins, different site sections of the web applications that should be part of the main or a unified experience. For example, a new site where each subsection, like the sports, politics, and culture belongs to their own subdomain, or another that's frequent, actually. We have seen it many times in e-commerce web application that has the homepage at example.com, and the listings, product, car pages are in different subdomains. This is also something that we have seen in cases where you have a product, you have customers, and you want to give them their own branded URLs. So you use subdomains with the name of their company. So they can have their own personalized URL. As we will see, this presents a lot of problems, especially because the user, in these cases, is not staying in a single origin, but moving across them back and forth and very frequently. Another reason is, and might have to do with legacy reasons, that these are mostly outside of the developer's control. For example, before most of the web migrated to HTTPS, it wasn't uncommon to see sites that have only certain sections in SSL. For example, the login and the checkout pages. They used subdomains so that they could separate these more secure parts of the site from others that were not in SSL yet. But after these companies migrating the rest of the site to HTTPS, they never moved these parts back to the main origin. So as you can see here, you have a site structure that has to do with a past decision that doesn't have any implication in today's world, in today's situation. But you still carry this decision to these days, and as we will see, these type of things also brings a lot of problems. Finally, we have also heard about some organizational needs. For example, companies use subdomains to isolate the work that different teams inside the company work on so they can separate them. Another reason we have heard is that sometimes they want to have analytics separated, the analytics reporting. They use subdomain because it's easier in some analytics tools to visualize the data from different subdomains. So they build the site in this way for that reason. So here's the list of the good and the bad uses of multiple origins. But before moving into the actual problems that these types of site architectures present, it is good to review some of the terms that we are using here. We're talking about origins and subdomains. But what exactly is an origin? So an origin is a combination of three things. The first one is the scheme, also known as the protocol, for example, HTTP or HTTPS. The second one is the hostname. And the third one is the port. Sometimes the port is not specified, so it's implicit, but it doesn't mean that the port is not there. So one of these three parts is different than the origins are entirely different. So let's suppose you are the owner of example.com and you create a subdomain at subdomain.example.com. Using a subdomain means that the hostnames are different. As we have seen, these are completely different origins, even when they have the same domain name. So when building a PWA, we have seen that many developers that have this type of site structure, they sometimes ignore the problems that they might have and they feel like as long as they are part of the same site, they belong to the same experience. So they are going to provide a single PWA experience to user. But in reality, they find that level of isolation between origins is much more strict than they thought it would be. The main reason for that is the same origin policy which imposes restrictions for sharing things like service workers, storage, and permissions. And these three things are actually three very important components when building a PWA. This might not be a huge problem in a site like this one, where the user spends most of the time navigating pages in example.com and only visits the login page at login.example.com once in a while to complete a very specific task. But what happens in a site like this one, where the user frequently moves across different origins during a single session? Let's review the problems that this might bring. The first one has to do with the offline experience and in this type of site architecture can be much more difficult to achieve. The reason for that is that the component in PWA that allows you to achieve an offline experience is a service worker and the service worker is tied to a single origin. So if you want to provide an offline experience across your site, you have to create at least one service worker per origin. As you might expect, this is not only more difficult to maintain. There's going to be three different files even when their own caching strategies and their own code, but also having multiple service workers running in your device consumes more resources. For example, CPU, memory, etc. Another problem that you might see is when you want to achieve great performance across your PWA and the reason for that has to do with local storage. So the different types of local storage like the Cache API and IndexedV that sometimes you might want to use to speed up the fetching of resources, for example, are also tied to a single origin. So let's suppose you create a local database with IndexedV in example.com. All the data that's in that IndexedV instance is not going to be available to the other origins. So they have to create their own. So if you have something like the user settings in example.com, you are not going to be able to access it unless you sync via the backend. Permissions are also scoped to origins, and this means that if a user granted a given permission to example.com, it won't carry over to other origins like subdomains. So in the case of any commerce web applications, imagine that you need to ask for the geolocation permission, which is very common in this type of web apps. Every time the user visits a new origin, they need to give the permissions again. Otherwise, you can't use that data. Another case, a video calling app that as we have seen before, you might give some dynamic, dynamic URLs for your customers and give them each of them a subdomain with their own company name. If you have your video calling logic or functionality posted in different subdomains, every time the user lands into one of these subdomains, they need to accept things like the camera or the microphone permission again. And finally, another problem that has to do with UX and is pretty disruptive is that every time you navigate through the web applications, you will see something like this, which is an out-of-scope bar informing the user that they have moved out from the main PWA experience. So having seen all these limitations and from the experience that we had working with many companies that are trying to build PWAs, if you're going to have one take away from this presentation, remember this one. You can build a single PWA experience, avoid dividing the site into subdomains. And if the site is already built in that way, migrating to a single origin is always the best approach. But in some cases, you might have a multi-origin site and you can't migrate to a single origin for different reasons, because it's difficult, because it takes more time, because it might have impact in different things. So in these cases, here are some workarounds or suggestions that you can explore. So if you have a site like this one where the user spends most of the time at example.com and moves to different subdomains rather infrequently, this is not very complicated. So you can just add your service worker and caching logic to the most frequently visited domain. And the same thing you can do in a site like this one, because in this case, the user is going to be navigated across potentially many origins, but there are some of them that might be more frequently visited or they are more important for you to provide things like an offline experience. In this case, you can, for example, add one service worker per, only one service worker in one of these origins. But if you do something like this where you add one service worker in each of the origins, keep in mind that this is going to be expensive in terms of resources. So at the very least, when the service worker installs and registers, try to keep the installation as light as possible. This diagram shows the steps that the service worker goes through when installs and performs a technique called pre-caching. Pre-caching is basically fetching resources from the network, the service worker install time so that you have these resources in the cache available when the user requests them. It could be at a later point. And usually during the pre-cache phase, you are going to fetch many more files that you need at a given point. So if you have something like this, try to keep that part lightweight because otherwise every time the new service worker is installed, the user jumps back and forth different origins, you're going to be bringing a lot of resources from the network. So you're going to be consuming a lot more bandwidth and a lot more resources. From the point of view of installability, nothing prevents you from prompting your users to install your PWA. So they can have a quick access icon and enjoy navigating in full screen mode and have this app-like experience. The only recommendation here is make sure that you're only showing the prompt in the main PWA origin. So going back to the previous example, if you have something like this, you should only show the prompt in example.com so that when the user installs the PWA, does the entry point to the PWA and avoid showing the prompt in any of the different sub-domains, basically. If you want to take a look at this article, it contains the latest installed criteria. It's going to let you know how to, for example, do what I just said, basically optionally showing the prompt in some parts of your site and not in others. And regarding this problem, which is quite disruptive for the UX, we have a new API, which is one of the main things that we wanted to discuss in this presentation, which is the Web App Scope Extensions API. And this API allows you to sites that control multiple sub-domains and top-level domains to be presented as a single web app. And in the first iteration of this API, what it allows you to do is that when your users are navigating across different sub-domains, you are going to avoid showing this out of scope bar, which is very disruptive. Implementing is actually very easy. You have in your main origin and manifest, you can add the list of the sub-domains that are related to your PWA experience. And then on the other side, on the each of these sub-domains, you can add a well-known Web App Origin Association file pointing back to this is the main origin. So that way you establish the relationship and then the browser knows that you own this group of domains and you consider them to be part of the unified experience so that these types of alerts are not being shown. Web App Scope Extensions is in origin trial, which means that you can apply here, you can register for it and you can use it in your site with real users. We are looking for feedback around these APIs and more cases that you would like us to support. So please let us know by reaching out or just leaving a comment in the comment section of this video. So this is all for multi-origin PWA, which is actually the idea of having a site that consists of multiple origins where you want to provide a single unified PWA experience. This article in Web.dev summarizes all the things that we have discussed until this point, so make sure to check that out. Before wrapping up, we wanted to focus a little bit on one of the cases that we mentioned at the beginning as one of the acceptable ones because this is actually something that's very common and has to do when you actually want to build multiple PWAs. Instead of a single one across multiple origins, in this case you want to build multiple PWAs and take advantage of the same domain name so the users can identify that these different PWAs belong to the same company or the same, let's say, parent product. So this is the case, graphically, basically. You have three different PWAs, no relationship between them, except from the fact that they belong to the same company or product and you want to kind of familiarize them. So one thing you can do in that case is to making them reuse the same domain name, right? So you can achieve that by using subdomains, for example. And here are some examples of this that we have seen in the real world. One example is, for example, a company that has subsidiary brands and they want to provide a PWA for each of these brands while they are tied to the same parent company, right? It's not uncommon, for example, in some businesses like if I have a shop and then I have two different brands, one of my brand sells shoes, the other one sells, I don't know, t-shirts. These two brands belong to me, so basically the main company and I create a different experience for each of them because the users might access them separately and even install them separately. So that's why. The second one is creating a specific PWA for a major event. For example, if you have a new site and the Soccer World Cup is coming and you want to create an app that's specialized on that only and let the users install it to receive notifications on that app, et cetera, then you can do something like this and you create workup.newsbrand.com and the user will see that's related to the main site but at the same time, you are going to be taking advantage of the level of isolation of multiple origins, in this case, to let them install as a standalone application. Another example is individual PWAs tied to the company's name. This is similar to the first one. Here you have three different PWAs, you have example.com and then you use a subdomain for each of them, right? If you see some of the Google apps, for example, use this, basically. So Schimel is mail.google.com, you have drive.google.com, meet.google.com, calendar.google.com. And thinking about these examples, it's going to be much more clear why in this case, isolation is something that you want because if you give permission for one of these apps, you might not want to give the same permission to others or you can even want to install them independently. Also, it makes sense for the mail app to have their own local cache that's not being shared with any other apps. So in this case, as you can see, you are using a subdomain, but at the same time, thanks to the domain name, you are making all these apps look as part of the same suite of interrelated apps. The isolation between these apps is because of the same reason that we talked about before, but in that case, it was actually a disadvantage. In this case, it's something good. And you can also have your own manifest in each of these PWAs, individual PWAs, so you can offer them to be installed individually. Other approaches that we have seen are companies that want to build multiple PWAs interrelated somehow are using a subpath. So in the case we have seen before, subdomains for these type of use cases is the right one. If you are thinking of something like this, don't do it. So there are many reasons why you don't want to do something like this when you are building separate PWAs. I'm not going to go into detail, but we are going to share resources for that. In this case, we have an article where we describe all the pros and cons of these approaches, but very quickly and kind of intuitively, think that in this case, we don't have the level of isolation that subdomains gives us. So let's suppose I have app one, and I want to give app one a given permission, so automatically giving this permission to all the rest of the apps. That sounds maybe something good, but what happens if I block permission for one app? It's going to be blocked for all of them. Same thing happens if I, for example, wipe the data from app one, then that's going to be also wiped for all the other apps. And there are many cases like that, attribution, for example. If I receive a notification, it's going to be hard to attribute to which app it belongs to. So many of these cases happen with this type of architectural pattern that's not recommended for this case. This is interesting. So in the first part, if you want to build a single PWA experience, using subpath is actually something that you want to do, but if you want to build separate ones, it's the opposite, right? So you shouldn't be thinking about this use case. So as we said, this is the article for this part of the presentation. Let's see now a recap of the two different things that we have explored today about multi-origin PWA. So in the first case, you want to build a single PWA. In this case, our recommendation is to avoid using multiple origins, like subdomains. And if your site is built in that way, migrating to a single origin is the best option you have. In the opposite case, you want to build multiple PWA's taking advantage of the same domain name. Something that's actually recommended is to use a different subdomain for each of these applications. And unlike the other approach, don't use path and have a PWA in a different subpath, because that's going to bring a lot of headaches and a lot of problems. And I think that's pretty much it. One reminder is that we have a website, besides WebDev that we have shared before, Chrome OS Dev slash Enterprise. We also have a lot of information that's more specific to Chrome OS. And you can see more articles and information there. I think that's pretty much it on my side, Rich. So going back to you to wrap this up. Yeah. Thanks, Damien. Yeah, as Damien mentioned earlier, please visit our Chrome Enterprise developer website. And there's additional articles and information on there to supplement your learning. We also have our channel on YouTube, the Chrome Enterprise developers channel that sits within the Chrome YouTube channel, where you can find additional videos about PWA's and relative content on there. That's it for this session. We look forward to seeing you at the next webinar. Thanks for joining. And have a great day.