Service Worker Travel Log - Day 9
Day 9 - I Forgot To Mention This
In my excitement to talk about Service Workers there are a few things that I did not mention up front that are pretty important. Also, having worked with Service Workers for the last year there are a number of tips I would like to share to make your journey smoother. So in this post let me discuss a few important points and in future post I will occasionally add some commentary on practical usage of Service Workers that was at times hard earned by myself.
There are three core operating principles of Service Workers that are required and make them safe and secure to sue.
First, Service Workers must be installed over HTTPS. In the context of using Service Workers with QuickBase this means that you save your Service Worker in a code page and by one mechanism or another cause the Service Worker to register using script similar to this:
Since QuickBase serves all its pages over HTTPS this first requirement is automatically achieved if you save your Service Worker in a code page.
Second, a Service Worker can only react to domain events that happen within the same origin (protocol, sub-domain and port). All QuickBase pages use the HTTPS protocol and are served over port 443. In practical terms the sub-domain requirement means that Service Workers you register in your QuickBase sub-domain cannot effect other sub-domains.
Third, Service Workers are registered to a particular scope and only react to domain events associated with the scope they were registered to. In our examples so far all of our Services Workers have registered to the scope of a particular table dbid. This is somewhat of an unusual situation compared to common usage of Service Workers as it tends to encourage registered multiple Service Workers to specific table scopes. There is nothing wrong with this approach but most sites using Service Workers register a single Servcie Worker with a scope of "/" (ie the entire site). Again this is perfectly acceptable and only reflects that fact that QuickBase is a multi-tenant cloud based service and that each tenant (ie user) has access to multiple applications / tables which should be managed by distinct Service Workers.
All three of these requirements collectively insure that Service Workers are safe and secure to use in general and with QuickBase in particular.
Next Up: Day 10 - Show Me More!
In my excitement to talk about Service Workers there are a few things that I did not mention up front that are pretty important. Also, having worked with Service Workers for the last year there are a number of tips I would like to share to make your journey smoother. So in this post let me discuss a few important points and in future post I will occasionally add some commentary on practical usage of Service Workers that was at times hard earned by myself.
There are three core operating principles of Service Workers that are required and make them safe and secure to sue.
First, Service Workers must be installed over HTTPS. In the context of using Service Workers with QuickBase this means that you save your Service Worker in a code page and by one mechanism or another cause the Service Worker to register using script similar to this:
var dbid = "bmtpmup9q";
var dbidTable1 = "bmtpmuqap";
if ("serviceWorker" in navigator) {
navigator.serviceWorker.register(dbid + "?a=dbpage&pagename=sw.js", {scope: dbidTable1});
}
Since QuickBase serves all its pages over HTTPS this first requirement is automatically achieved if you save your Service Worker in a code page.
Second, a Service Worker can only react to domain events that happen within the same origin (protocol, sub-domain and port). All QuickBase pages use the HTTPS protocol and are served over port 443. In practical terms the sub-domain requirement means that Service Workers you register in your QuickBase sub-domain cannot effect other sub-domains.
Third, Service Workers are registered to a particular scope and only react to domain events associated with the scope they were registered to. In our examples so far all of our Services Workers have registered to the scope of a particular table dbid. This is somewhat of an unusual situation compared to common usage of Service Workers as it tends to encourage registered multiple Service Workers to specific table scopes. There is nothing wrong with this approach but most sites using Service Workers register a single Servcie Worker with a scope of "/" (ie the entire site). Again this is perfectly acceptable and only reflects that fact that QuickBase is a multi-tenant cloud based service and that each tenant (ie user) has access to multiple applications / tables which should be managed by distinct Service Workers.
All three of these requirements collectively insure that Service Workers are safe and secure to use in general and with QuickBase in particular.
Next Up: Day 10 - Show Me More!