jgaehring
commented
6 years ago For the last 2 days I've been familiarizing myself with the Drupal/farmOS environment, and re-familiarizing myself with the Service Worker spec.
First, the good news: service workers get along very well with the Drupal architecture! Just about as well as any SPA, to the extent that I think we no longer need to think of the server-sidedness of Drupal as any kind of drawback where SW's are concerned. With the bit of boilerplate @mstenta provided me, I was able to get a SW registered in pretty short order and cache a few static assets to the browser's storage.
It doesn't matter whether it's a SPA or not because of a neat design feature of the service worker which I had forgotten. As long as the service-worker.js file itself (the one that gets loaded into the browser) is placed at the website's root directory, it can control all other resources in that directory and all its subdirectories. The file that points to service-worker.js and tells the browser to register it can be at /farm/assets/plantings/farm_offline.js or anywhere and everywhere in the site, but they will all share a single service worker, and the service worker can cache all endpoints and all their assets, no matter what page initially told the browser to register it. So cool!
Where Drupal starts to complicate things is when it comes to telling the service worker what resources to cache, because Drupal generates loads of urls and they're all potentially dynamic.
But that brings me to the second piece of good news: the Progressive Web App module handles all this marvelously. The module provides all the necessary urls to the service-worker.js and then makes sure that script is registered at root. Not only that, but it targets almost all (and I'll get to that 'almost' part below) of the offline use cases we have, and without any extra bloat. Apparently this module has been proposed to be included in Drupal Core, and for good reason; the author, nod_, is the JavaScript maintainer for D7 and D8 and he's used some very good patterns in developing the SW. I added the module to farmOS and it ran like a charm, with a few hiccups (upon enabling it I got the errors mentioned here, but it still worked). Since I'm only testing this locally I had to use devtools to mock 'offline' use, and it definitely needs real-world testing, but right out of the box it's caching the entire site and most of its assets (images are not cached by default, but that can easily be reconfigured). Looking at it now, I'm not sure we need to relegate this functionality to a special div like we originally discussed. If it tests well, it may be easiest to just let it loose on the whole site, rather than create extra work to confine it.
So this guy's pretty much done all my work for me. Except for that 'almost' part I mentioned above. The one use case this library doesn't address is the most significant one, which is handling offline PUT requests and caching their payload until connectivity is restored. And he excludes that feature for good reason, as I've learned, because it relies on a part of the Service Worker API which is non-standard. It is supported by current versions of Chrome and Firefox, and Edge has it behind a flag, but until it's on a track to become a standard, it should be considered unstable.
Given that farmOS' users can be given the choice to opt in on experimental features, I'm still game to try to develop this and see where it goes. And this might be where the idea of an overlay div or something similar might come back into play. Another possibility might be to reroute those requests to something like an /outbox page where the user can view updates that are still in cache but haven't been pushed to the server yet (and this reroute is possible, in theory, because the service worker lives at root). And if we still want to pursue the SPA idea, this could be the seed for that. So in other words, nod_'s PWA module would handle the offline read requests, while the (experimental) farm_offline module would handle offline write requests.
At least, that's my perspective on it so far. Does that make any sense?
mstenta
alexadamsmith
This module came out of discussions with @jgaehring and myself in this issue: https://github.com/farmOS/farmOS/issues/37
The idea is to create a fully browser-based solution to the problem of offline access to the farmOS application, using Javascript and service workers. We decided to start this module as a place to experiment with those ideas.
If this approach makes sense, it may become the starting point for an offline-first UI in the farmOS 8.x-2.x branch (on Drupal 8).
Rough plan:
The fourth step ("Provide some basic features") is obviously the biggest piece, effort-wise, and should be broken up into separate tasks once we get the initial proof-of-concept working (steps 1-3).