Re: [ServiceWorker] Response streaming and SW lifetime (#651)

It's a deep question, and not one we have an answer to today.

On one hand, SWs are lighter-weight (by design) than an iframe, so the price of having it open to service interactive content seems low. We're currently getting to a place where we can get real-world data about memory/cpu/latency from deployed SWs.

On the other hand, in cases where the SW might be (naively) allocating memory over the long period of time, we might be forced to kill it regardless and that behavior will look bad. E.g., the SW will need to handle a future range request when the video plays, issuing a new `onfetch`.

I think the bigger issues here are likely to be down to responsiveness. How do we make sure such a video-serving worker doesn't starve other requests for time? Maybe this is a case where we should find a way to use a sub-worker from the SW or a parallel SW (second, third, whatever).

Also, I think we have pretty much this exact issue when dealing with websockets. I've punted on both so far. Thoughts from others would be most helpful.


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