 Hi, my name is Demian and I work at Google as a partner engineer. This is the second video of a two-part series about progressive web apps on sites that consist on multiple origins. In the first talk, PWAs in multi-origin sites, we went over the challenges that developers face while building PWAs that encompass multiple origins. As we saw in those cases, the recommendation is avoiding this type of site architecture where different origins, like subdomains, are part of a unified PWA experience. For those that already have sites built in this way, migrating to a single origin is the best option. In this talk, we will take a look at the opposite case. Instead of a single PWA across different origins, we'll analyze the case of companies that want to build multiple PWAs, taking advantage of the same domain name. Keep in mind that all the use cases, APIs, and techniques that we will cover belong to the open web, so they are not tied to a specific platform and they affect PWAs in any form factor, like mobile and desktop devices. Let's get started with today's topic. In some cases, you might want to build independent PWAs, but still identify them as belonging to the same organization or brand. Sharing the same domain name is a good way of establishing that relationship. Here are some examples. The first one is building an individual PWA experience for subsidiary brands tied to the main company brand. For example, a company that has an e-commerce site at parentcompany.com that wants to let its subsidiary brands have their own PWAs while making sure users understand that they belong to the parent's brand. Another example is creating a PWA that will be used temporarily for a certain event. For example, a sport news site that wants a specific app for a major sporting event like the Soccer Workup to let users receive stats about their favorite competitions via notifications, and then installing as independent PWAs while making sure users recognize it as an app built by the parent news company. Another example is a company that wants to build many PWAs and wants them to work as independent apps tied to the company's name. Their recommended approach in cases like this is for each conceptually distinct app to live in its own origin. If you want to use the same domain name inside all of them, you can do that by using subdomains. You can find this pattern applied to Google apps that you might use every day. Each of them runs on its own subdomain, which provides a level of isolation to let them act as individual apps. At the same time, they are united by the same domain name that identifies the parent company or product. Using distinct origins for each individual PWA is a safe choice due to the same origin policy. The same origin policy imposes isolation between service workers, storage including cache, local storage and basically all forms of device local storage and permissions. Thanks to that, users will know exactly which service they are giving permissions for and features like notifications will be properly attributed to each app. Finally, each app has its own manifest file and can offer its own install experience. Let's take a look now at other approaches. As discussed, the best way to build multiple independent PWAs that share the same domain name is to use a different subdomain for each of them. However, we have seen other strategies implemented by developers with the same goals but that have some limitations, so we don't recommend them. There are cases where developers use the same origin for all their PWAs and implement each of them in a different path. Using a single origin is a good practice if you are building a single PWA experience, but if you want to build multiple PWAs, this presents many limitations. The root of these problems stems from the fact that the browser won't fully consider these to be distinct apps. Let's review the problems one by one. The first one is storage. With this type of site architecture, all forms of device local storage are shared between apps. For that reason, if the user decides to wipe local data for one app, it will delete the data from the whole origin. There's no way to do this for a single app. Permissions are also tied to the origin. That means that if the user grants permission to one app, it will apply to all apps simultaneously in that origin. Not having to ask for a permission multiple times may sound like a good thing, but remember if the user blocks the permission to one app, it will prevent the others from requesting that permission or using that feature. Settings are also set per origin. For example, if two apps have different font sizes and the user wants to adjust the zoom in only one of them to compensate for it, they won't be able to do it without applying the setting to other apps as well. These challenges make it difficult to encourage this approach. Nevertheless, if you can't use a separate origin like Subdomain as discussed at the beginning of this talk, do your best to at least avoid the following patterns. Let's suppose you want to build two PWAs using path on example.com. If you can't use Subdomain, it is preferable to use non-overlapping path like in this example where Slash App 1 and Slash App 2 are path starting from example.com than using overlapping or nested path like in this example where there is an inner app at example.com Slash inner and an outer app at example.com. The problem with this approach is that all URLs in the inner app will actually be considered part of both the outer app and the inner app. This brings a whole new set of problems. If you install the inner app, the outer app will never show an installation banner. There are also problems related to attributions with some APIs like notifications and the batching API. Another problem is that the outer app might mistakenly capture links that belong to the inner app. Let's do a recap about different strategies to build multiple PWAs using the same domain name. The first one is using different origins. As discussed, the best way to build multiple independent PWAs that share the same domain name is to use a different Subdomain for each of them. Another approach is to use the same origin. If you can't use a Subdomain, it is preferable to use non-overlapping path like in this example where slash app one and slash app two are path starting from example.com. But remember, this configuration still presents a lot of challenges, so we can't consider it a recommended approach. A variation of this strategy is to use overlapping or nested path. As we have seen, this brings an additional problem. All URLs in the inner app will actually be considered part of both the outer app and the inner app, and that can bring a lot of problems with use cases and APIs. That makes its architecture the least recommended approach. Here is the final list of ways of building multiple PWAs on the same domain. You can read more about this topic in our companion article in web dev by following this link. And in case you haven't, don't forget to check out the first video of this series, PWAs in Multi-Origin Sites, where we explore the opposite case, trying to build a single progressive app that encompasses different origins, like Subdomains. I hope you have enjoyed this talk. Thanks for watching.