Re: [ServiceWorker] Worker-As-A-Service service workers (#744)

I see service workers as fast response, low load entry point routers, with regular and shared workers as the intensive processing centers. Service worker is to nginx as regular/shared workers are to backend application/API/database servers.

I can see a bpg2jpg.github.io/api or a navigator.connect working in a similar way: its service worker passes off to a worker to do the heavy lifting. If the service worker does the heavy lifting, then that just sounds like a regular worker to me. But if that heavy lifting also includes fetch URL routing, that will likely lead to slow responses for those URL requests.

I can even see a fancy far future where the browser could decide to put a service worker into a sleep mode, evict it from memory and then rehydrate it once the regular/shared worker finishes its intensive work and gives the response back to the service worker. That is really far away, and has some serious challenges, but by strictly partitioning the responsibility of service worker to just fast response routing, it allows considering those types of optimizations since the range of use is constrained.

So I do not believe cross-origin service worker communication inherently solves the problem we are encountering in the Mozilla Gaia email case. I still prefer to see service workers using regular/shared workers over cross origin service worker communication, if that choice has to be made. 

In the email case, the main issue is that browser windows showing email UI need to all use the shared worker already, and it is more efficient from a memory and code location/development reasons for the service worker to communicate with that shared worker. In that case, all the browser windows, shared worker and service worker are on the same domain.


---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/744#issuecomment-137914236