Remote service workers

[mfulton26]

First, some things I love about Deno Deploy for context:

• it implements the FetchEvent for handling incoming requests just like service workers do inside a web browser
• setInterval can be used to do some task periodically (e.g. check some API that doesn't support pushing updates)
• code running in different regions can communicate with one another via BroadcastChannel
• some KV store is on the roadmap (see #76) and Cache API is planned (I could see supporting an IndexedDB implementation down the road too)

What I feel is missing and that I suspect will become more important as a KV store and other things becomes available:

• install event for setting things up prior to replacing a prior deployment
• activate event for cleaning up things from a prior deployment
• periodicsync event if that helps in better managing background tasks (using setInterval may mean a deployment is never truly idle enough to be replaced by a new deployment)
• programmatic removal of prior deployments

I want to be able to use Deno Deploy a lot like local service workers (and with the same API where possible) except ran in a trusted environment (not in a user agent where code and application data can be modified).

I think that implementing more of the service worker API and events should enable stopping tasks in a prior deployment like periodic syncs, transfering data and/or upgrading caches/data/etc., and transitioning traffic to a new deployment while removing/disabling the prior one (allowing traffic to old ones could be problematic if an install of a new version changes cache/data schemas, etc.).

i.e. I want to be able to manage the life cycle of my deployments more and treat them more like service workers so that I can better transition tasks and data from deployment to deployment.

[bnoordhuis]

Thanks for the feedback! install and periodicSync are on our roadmap. W.r.t. your other points, can you elaborate what for you the use cases are for:

1. The activate event. What would you clean up?

2. Removing old deployments. Deploy's model is that deployments are immutable and permanent.

[mfulton26]

Is there a public roadmap for reference?

Once the Cache API is implemented, install can be used to populate a cache and activate can be used to remove old caches. Similar things apply if IndexedDB gets implemented down the road.

If deploys are meant to be permanent then that could be challenging when iterating on data schemas. A new or old deploy could insert data in a format not supported by a different deploy. Maybe rejecting requests on old deploys is a feature that projects need to create on their own but that may be onerous.

[mfulton26]

I think activate may not be needed if new deployments can't replace old deployments. Would it be possible to have an alternate deployment strategy where deployments continue to be immutable but a new deployment replaces the prior deployment? That way workers using old data formats get replaced with new workers that upgrade data as needed and use new formats going forward.

[mfulton26]

I see that addEventListener("fetch", ...) is being phased out (https://github.com/denoland/deploy_feedback/issues/71#issuecomment-889760772)

I'm not sure what this means for the future of remote service workers and Deno Deploy but I hope it will be reconsidered in the future as having a web browser (or hopefully Deno Deploy one day) manage the lifecycle of workers, migrating data, etc., etc. in a distributed and easy way seems to have so much promise to me

thank you