With all major browser now supporting
Service Workers I will be deploying a
Service Worker to
all of my QuickBase applications both public and private. This deployment will happen some time between now and the time of the
Empower Conference. What follows is a description of the architecture I will be using.
I have a application entitled
SW Master (with dbid=
bnpp6kt9s) which currently has no tables but does have three
code pages named as follows:
- registration.html
- swmaster.js
- account.js
The
registration.html page contains some simple code that will cause the code page
swmaster.js to be registered as a
Service Worker with a scope of my entire account. In practice I will embed the
registration.html page in the dashboard of select applications as a web page widget. When a user visits this application the code in
registration.html will cause the
Service Worker in
swmaster.js to become registered. At this point the user who triggered the registration will have every application in my account controlled by the
Service Worker in the code file
swmaster.js
Within
swmaster.js there is code that will append
three <script> tags to the bottom of
every navigated page QuickBase serves. If the user is currently viewing page associated with the
Pastie table (dbid=bgcwm2m4g
), the appended code will look something like this:
<script src='bgcwm2m4g?act=dbpage&pagename=table_bgcwm2m4g.js'></script>
<script src='bgcwm2m4g?act=dbpage&pagename=application.js'></script>
<script src='bnpp6kt9s?act=dbpage&pagename=account.js'></script>
The
first script will point to a
code page named
table_<dbid>.js where
<dbid> is the
dbid of the current page's URL (the dbid
bgcwm2m4g is for the Pastie Table
). Code in
table_<dbid>.js (eg
table_bgcwm2m4g.js) will be responsible for customization or feature enhancements you want to add to a
any page associated with a particular table. Unlike the
IOL technique which are only operate against {new, view, edit, table report and gridedit} pages the injected script will apply to every page associated with the table including administrative and non-table reports.
The
second script will point to a code page named
application.js in the current application. Code in application.js will be responsible for application branding or application wide feature enhancements you want to add to every page in your application.
The
third script will point to a code page in
SW Master named
account.js. Code in
account.js will be responsible for account branding or account wide feature enhancements you want to add to every page in your account. Initially I will place code in
account.js that will draw a red horizontal line across the top of the page to give visual feedback that
Service Workers have been enabled.
The net effect of adding these three
<script> tags is that you will get fine grain control of injecting script based on the
(1) table,
(2) application and
(3) account (ie subdomain) that is currently being accessed.
We will be accomplishing all of these features enhancements with a
single Service Worker because we will consistently be using the convention of naming the code pages
table_<dbid>.js,
application.js and
account.js. If none of these code pages exist, the application will work as if the
Service Worker was not doing anything.
It may sound complicated but this architecture has been carefully thought out over almost three years and it will blow your mind what you can do using
Service Workers.