Service Worker Travel Log - Day 3
I just got called out of town so you get Day 3 early ...
Day 3 - Show Me Already!
Okay so today is the big reveal - our first Service Worker in QuickBase. Isn't it exciting!
So how about this: Let's log all the things - not SOME of the things - ALL of the things. Our first Service Worker will simply log EVERY URL QuickBase accesses. Now I have to take some precautions since this is a demo that will get visited by hopefully a lot of people over time and I don't want to keep coming back to clear the log of ALL the things. So I am simply going to log to the developer console every URL QuickBase accesses. If you actually wanted to implement a real log you could easily arrange for the URL and other relevant information to be stored in a QuickBase table or an external store using an appropriate HTTP API method. We will do our logging from within a Service Worker.
So let's start our journey by visiting our application dashboard:
QuickBase Service Worker Travel Log Dashboard
https://haversineconsulting.quickbase.com/db/bmtpmup9q
Nothing happens and our Service Worker icon didn't light up yellow.
Well in fact we did register a Service Worker but we set its scope to be the relative path "bmtpmuqap" (Table #1). What this means is that our Service Worker will only activate when accessing some page within Table #1. If you visit some page within Table #1 and press F12 to display the console you will see hundreds of URL spray out as QuickBase makes a network request for each URL it needs to build the page. If you visit Table #2 or the application dashboard there will be no Service Worker in scope and nothing special will happen.
You should see something like this:
How did we do it? Well on the dashboard of the application there is a Web Page Widget stored as a code page named reg.html that displays no visible content but contains the appropriate JavaScript to register a Service Worker to the scope "bmtpmuqap" (Table #1):
https://haversineconsulting.quickbase.com/db/bmtpmup9q?a=dbpage&pagename=reg.html
Now our Service Worker is itself saved in a code page named sw3.js:
https://haversineconsulting.quickbase.com/db/bmtpmup9q?a=dbpage&pagename=sw3.js
You can ignore the first two event listeners for now - they are simply there to make the Service Worker load really quick and boot out any previously registered Service Worker.
The real action is in the third event listener. What it does is simply wait for a fetch event (ie a network request for an asset) and logs the URL to the console.
This particular behavior may not appear to be too practical for logging but we want to drive home two points.
First, a Service Worker can act as a network proxy and can intercept any network activity and (1) let is pass through as normal or it can (2) substitute or (3) modify the request or response.
Second, Service Workers listen for Domain Events not DOM Events. DOM Events are generated in the browser and include mouse clicks, keystrokes or a screen scroll. A Domain Event is a different thing altogether and includes such events as (1) the fetching of a URL across the network, (2) the regaining network activity after being offline or (3) a server push event.
Next Up: Day 4 - Just Give Me Some of the Things
Day 3 - Show Me Already!
Okay so today is the big reveal - our first Service Worker in QuickBase. Isn't it exciting!
So how about this: Let's log all the things - not SOME of the things - ALL of the things. Our first Service Worker will simply log EVERY URL QuickBase accesses. Now I have to take some precautions since this is a demo that will get visited by hopefully a lot of people over time and I don't want to keep coming back to clear the log of ALL the things. So I am simply going to log to the developer console every URL QuickBase accesses. If you actually wanted to implement a real log you could easily arrange for the URL and other relevant information to be stored in a QuickBase table or an external store using an appropriate HTTP API method. We will do our logging from within a Service Worker.
So let's start our journey by visiting our application dashboard:
QuickBase Service Worker Travel Log Dashboard
https://haversineconsulting.quickbase.com/db/bmtpmup9q
Nothing happens and our Service Worker icon didn't light up yellow.
Well in fact we did register a Service Worker but we set its scope to be the relative path "bmtpmuqap" (Table #1). What this means is that our Service Worker will only activate when accessing some page within Table #1. If you visit some page within Table #1 and press F12 to display the console you will see hundreds of URL spray out as QuickBase makes a network request for each URL it needs to build the page. If you visit Table #2 or the application dashboard there will be no Service Worker in scope and nothing special will happen.
You should see something like this:
How did we do it? Well on the dashboard of the application there is a Web Page Widget stored as a code page named reg.html that displays no visible content but contains the appropriate JavaScript to register a Service Worker to the scope "bmtpmuqap" (Table #1):
https://haversineconsulting.quickbase.com/db/bmtpmup9q?a=dbpage&pagename=reg.html
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Service Worker Registration Page</title>
</head>
<body>
<script>
if ("serviceWorker" in navigator) {
navigator.serviceWorker.register("bmtpmup9q?a=dbpage&pagename=sw3.js", {scope: "bmtpmuqap"});
}
</script>
</body>
</html>
Now our Service Worker is itself saved in a code page named sw3.js:
https://haversineconsulting.quickbase.com/db/bmtpmup9q?a=dbpage&pagename=sw3.js
self.addEventListener("install", event => {
event.waitUntil(self.skipWaiting());
});
self.addEventListener("activate", event => {
event.waitUntil(self.clients.claim());
});
self.addEventListener("fetch", event => {
console.log(event.request.url);
});You can ignore the first two event listeners for now - they are simply there to make the Service Worker load really quick and boot out any previously registered Service Worker.
The real action is in the third event listener. What it does is simply wait for a fetch event (ie a network request for an asset) and logs the URL to the console.
This particular behavior may not appear to be too practical for logging but we want to drive home two points.
First, a Service Worker can act as a network proxy and can intercept any network activity and (1) let is pass through as normal or it can (2) substitute or (3) modify the request or response.
Second, Service Workers listen for Domain Events not DOM Events. DOM Events are generated in the browser and include mouse clicks, keystrokes or a screen scroll. A Domain Event is a different thing altogether and includes such events as (1) the fetching of a URL across the network, (2) the regaining network activity after being offline or (3) a server push event.
Next Up: Day 4 - Just Give Me Some of the Things
