Re: [w3c/ServiceWorker] allow service workers to created nested dedicated workers (#1529)

A while back in whatwg/html#8362, I made several comments describing real-world use cases for service workers spawning dedicated workers. I’m concisely summarizing them here too, since I this space might be more likely to trigger implementer interest.

An [MDN webpage on offline progressive web apps](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Tutorials/js13kGames/Offline_Service_workers) says, “If you have heavy calculations to do, you can offload them from the main thread and do them in the worker, and receive results as soon as they are available.” In actuality, whenever a service worker needs to do CPU-expensive work, it must resort to complex coordination with at least one dedicated worker belonging to its origin’s browser tab(s), e.g., using Web Locks and some [leader-election](https://en.wikipedia.org/wiki/Leader_election) scheme. (This can get especially complicated when the leader tab gets closed, destroying its dedicated worker, and the newly elected leader tab must restore that dedicated worker’s state.)

This complexity affects the following use cases:

* **Offline SQLite, OPFS sync access, local storage**: Cache, IndexedDB, and cookies are currently the only persistent offline data storage available to service workers. A progressive web app that wishes to be available offline is unable to use without the aforementioned complex coordination with dedicated document workers; it must use IndexedDB or the like.
    * OPFS sync access is essential for WASM SQLite; it is currently impossible for an offline website’s service worker to fetch data from SQLite data in OPFS without coordinating with at least one dedicated worker belonging to its origin’s browser tab(s). See rhashimoto/wa-sqlite#95, rhashimoto/wa-sqlite#81, DallasHoff/sqlocal#39.
    * If service workers could use OPFS, webpages that are loaded from URLs typed into the address bar can be dynamically generated offline by the service workers. For example, a cloud document editor, wiki, CMS-based blog, or Pokédex web app that wished to make itself available offline could dump all of its documents’, wiki’s, or CMS’s data into a SQLite database, then use its service worker to dynamically generate the same web pages offline.
    * Furthermore, browser tabs would be able to use the same HTTP API both to read/write data in cloud storage and to read/write data to SQLite files or other documents in OPFS. When the service worker acts as a “transparent” mediator syncing cloud storage and with local caching, document scripts do not have to be concerned with whether documents are stored offline only, online only, or both.

* **Transparent decoding/decompression of unsupported file formats**: Service workers can intercept data fetches and transparently encode/decode data into new formats when the formats are unsupported by current browsers.
    * However, as said in https://github.com/whatwg/html/issues/8362#issuecomment-1271704657, custom decoding/decompression algorithms are CPU intensive and should be put in dedicated workers to avoid blocking the service workers. This is currently impossible.
    * A real-world case of this is [libjxl’s WASM decoder](https://github.com/libjxl/libjxl/tree/v0.11.x/tools/wasm_demo) for progressive enhancement of JPEG-XL images on a website. Ideally, the service worker would be able to perform the decoding process in a worker, to prevent blocking the service worker from other tasks (a tab→SW→worker→SW→tab dataflow path). However, because the service worker cannot currently spawn workers, it must use a [convoluted tab→SW→**tab→worker→tab**→SW→tab dataflow path](https://github.com/libjxl/libjxl/blob/v0.11.x/tools/wasm_demo/README.md).

* **Expensive RegExp processing for navigation routing**: A core use case of service workers is offline URL routing, but this routing may be expensive. As @wanderview mentioned in this issue’s original post, a real-world case of this is chromeos.dev’s >1.0-second synchronous microtask delay while processing complex regular expressions; see https://github.com/chromeos/static-site-scaffold-modules/issues/40#issuecomment-673591331.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1529#issuecomment-2641345477
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1529/2641345477@github.com>