Support Service Worker Foreign Fetch

[abdulhannanali]

Foreign Fetch is a new upcoming upgrade coming to service workers which will allow a Service Worker run across various origins and this provides Package Delivery platforms such as Unpkg working over CDNs such as Cloudflare a much more granular control over the caching of their assets on a browser.

I ❤️ Service Workers and would like to help in making the unpkg the first one to support Cross Origin Service Workers, I would love to work on a fork and create a WIP PR , if there's enough interest from the unpkg to support this in future.

Even if it's merged, it won't harm in any way, since it's a progressive enhancement and in case of absence of support in browser. Nothing happens. We can further discuss what is going to be our caching mechanism for the assets. Thanks a lot!

[abdulhannanali]

Also, everyone might not need this header which enables cross origin service worker, in this case, maybe we can use a flag in the url for it to be enabled.

[abdulhannanali]

@mjackson Any comments on this, please?

[mjackson]

Sorry for the slow response 😅

What are some things that you are hoping to accomplish with the service worker?

EDIT: I should also add that I think this would be really cool, but I'd like to figure out what our use cases are first.

[mjackson]

@abdulhannanali Still interested in working on this? I'm curious to hear your ideas.

[abdulhannanali]

Hey @mjackson !

I apologize for this long delay. I am definitely interested in working on this. The service worker in case of foreign fetch will be used to provide much more granular control over the Cache. Since Foreign Fetch Service Workers are designed to use with services such as

• Generic Content Delivery Networks
• Image Hosting Sites
• Fonts etc.

Offline First CDN

UnPkg can be the offline first CDN, and even though many of the applications that are PWA hosted bundle their own modules, there can be even faster load times, UnPkg can serve as a primary CDN for many PWAs decreasing their load times collectively as many of the dependencies and polyfills are going to be used universally in many PWAs, React, Polymer etc. all are popular choices and if we guarantee that the users can leave the CDN Caching Part to Unpkg PWAs performance will collectively increase. This can be convincing for application owners to use Unpkg instead of bundling major dependencies for their application. In case if cached, there can be faster first page loads, which are equally important when building a PWA, as much as the subsequent page loads.

Comparison with HTTP Cache

Since this is also a progressive enhancement, I don't think if PWAs reliance on this right now is any more useful than the reliance on HTTP Cache. HTTP Cache caches here aggressively but Foreign Fetch in future will provide us a better mechanism of caching all the needed assets.

Inter Service Workers communication

Unpkg acts as a proxy here, but multi service worker applications can also be a possibility thanks to foreign fetch in the future. Since it's merely a proxy we can modify headers a bit when they pass through SW to tell the users that they are coming from Foreign Fetch and based on that the client service worker can skip the caching of this resource conserving space for the user

Optimistic Fetching

Not sure, If all developers will be happy with that, but it's something that can certainly be supported in the future. Maybe as an experimental feature, and something fun to work on. Unpkg can collect statistics and based on that decide, if it makes sense to download a certain package, depending on our download patterns.

All this while not annoying the user

We should be doing all this, while, making sure, that the users and developer both don't get annoyed, so having a very fixed quota and not exceeding that in any case, is important for us. The discussion on quota can be moved further but ideally, we should be able to manage the dependencies in the cache based on their usage. IMO, Blindly just storing and demoing unpkg as a true offline first CDN will be a losing debate, since, when we talk about Offline First we are talking about regions where low performant devices rulezzzz, I also have a pretty 💩 Samsung mobile from 2014, which has a 🐌 🐌 🐌 spead

Encouraging browsers to adopt

If the Unpkg implementation is a success hopefully it encourages other browser vendors to start working on the Foreign Fetch in their browsers and encourage chrome to get it to stable faster and supported without origin trial.

This is I say about the Foreign Fetch

While Super Nice FRAGILE at best

Looking forward to hear what do you think and if this feature and future makes sense for Unpkg.

Also, From now on, I'll reply quicker. Sorry for this delay ❤️

[mjackson]

Thanks for your comments, @abdulhannanali :)

HTTP Cache caches here aggressively but Foreign Fetch in future will provide us a better mechanism of caching all the needed assets.

How is a foreign fetch SW better than the HTTP caching we have right now? Can you be more specific? Right now we set Cache-Control for a year for fully-resolved requests.

[mjackson]

Looks like the conversation has stalled here, so I'm going to close. However, I agree this would be really interesting. Also, it looks like foreign fetch may be removed from the spec, so we should definitely keep an eye on that.

Thank you for the discussion, @abdulhannanali!