Move from Google Cloud Storage API URLs to Google Cloud CDN

[jeffposnick]

Right now, we upload copies of the pre-built Workbox runtime libraries to Google Cloud Storage, and advertise URLs like http://storage.googleapis.com/workbox-cdn/releases/4.0.0-beta.1/workbox-sw.js as the "official" CDN.

Each requests against that sort of URL ends up hitting the Google Storage API, though, which incurs a bit of extra latency and cost.

We should look into using something like https://cloud.google.com/cdn/ in front of those Google Storage API URLs, and switch over the "official" CDN URL as needed for future versions (while still keeping the old URLs around).

[SukkaW]

@jeffposnick

I think, using open source public cdn service rather using "official" google cdn might be a better solution.
There are already many open source public cdn service, such as cdnjs, unpkg, jsDelivr and so on. They are widely used and relatively reliable.

Currently I am maintaining workbox-cdn@npm with nuxt-community, so that we can load workbox lib from unpkg and jsDelivr. It would be better if workbox team could officially maintain a pre-built runtime libraries repository at GitHub or NPM.

[jeffposnick]

So I think the main thing that prevented us from using, i.e., unpkg initially was the fact that what we publish to npm is different from the pre-built modules that need to be loaded from inside the service worker.

If there's a way to get a third-party CDN to serve our pre-built modules (which are effectively IIFEs, in the format that can be loaded via importScripts()) we'd be open to that.

[CTassisF]

(I don't know how things work at Google but...)

Maybe you guys can host workbox on www.gstatic.com (like Firebase does with its JS library - https://www.gstatic.com/firebasejs/5.9.1/firebase.js) or on ajax.googleapis.com (which seems to have been discontinued but still works - https://ajax.googleapis.com/ajax/libs/angularjs/1.7.8/angular.min.js).

I think this will be much simple to maintain because you'll won't have to worry about having a domain, managing DNS, managing a custom SSL certificate (because Google-managed SSL certificates are not covered by any SLA yet) etc.

[jeffposnick]

Yup, we are exploring our options, including the precedent set by other public SDKs hosted by Google.

One of the other considerations is that we need to have a good amount of control over when the CDN copy of a given release goes live, so that we could coordinate that with npm publishing. If we publish to npm and then it takes minutes or hours before the CDN is fully deployed, then that's a period of time in which a new service worker created with one of our build tools might call importScripts() on a non-existent CDN URL.

Publishing directly to Google Cloud Storage gives us a lot of control over that at the moment.

[SukkaW]

Although infrastructure managed by Google or workbox team, such as Google Storage API or Google Cloud Platform, is fully controllable, but some of them is sometimes unavailable to some countries or areas.

I suggest remaining managed infrastructure as default config in workbox lib to ensure every single pre-built module is available, but allow developer to choose serve from custom server or third-party CDN (leave developers to check if current version of workbox is reachable on third-party CDN, like jsDelivr or unpkg), just as workbox currently doing.

[CTassisF]

Although infrastructure managed by Google or workbox team, such as Google Storage API or Google Cloud Platform, is fully controllable, but some of them is sometimes unavailable to some countries or areas.

I suggest remaining managed infrastructure as default config in workbox lib to ensure every single pre-built module is available, but allow developer to choose serve from custom server or third-party CDN (leave developers to check if current version of workbox is reachable on third-party CDN, like jsDelivr or unpkg), just as workbox currently doing.

Agreed.

Google Cloud Storage is a not-so-great CDN solution. To be honest I had to do this workaround below to avoid its issues (because most corporate/educational firewalls block storage.googleapis.com):

var workboxVersion = "4.1.1";

try {

  importScripts("https://storage.googleapis.com/workbox-cdn/releases/" + workboxVersion + "/workbox-sw.js");

} catch (exception) {

  var workboxPathPrefix = "workbox-v" + workboxVersion + "/";

  importScripts(workboxPathPrefix + "workbox-sw.js");

  workbox.setConfig({
    modulePathPrefix: workboxPathPrefix
  });

}

Being able to use a proper CDN (like jsDelivr or even gstatic.com) solves that issue for me.

[jeffposnick]

I'd encourage folks to import Workbox from a first-party URL if you're concerned about the CDN not being available for a percentage of your target audience. Based on that code sample above, if you're going to the trouble of hosting a copy of the Workbox libraries locally already, you might as well prefer that copy over the CDN copy.

I think longer-term, the direction we see folks going is to create their own custom bundles that contain their service worker logic along with along the exact Workbox code that they need, via the approaches outlined in https://developers.google.com/web/tools/workbox/guides/using-bundlers

We do still plan on offering a CDN solution, and we do plan on moving off of storage.googleapis.com, but that's all to say that there are other options already available.

[jeffposnick]

Given that the focus in v5 is on modes in which you produce your own local bundles, I now think it's not worth the effort to move off of the Google Cloud Storage API.