Repository navigation
Will Service Workers be considered as a use case? #62
Description
Service Workers are different.
They are registered by a script.
But restarting/reloading the app with a service worker in control will intercept requests.
This incudes requests for import
A Service Worker can receive messages via postMessage.
A Loader has a message port too.
A Loader can preload global code, but it is also possible to load source code and augment it.
So I definitely see how a loader could be used to create a similar experience to controlling service workers, even though the registration/installation process is a bit different to service workers.
Is that a use case that is or maybe should be considered by this group?
Or was it considered?
If loaders are here to stay and would in principle enable all features service workers enable, that would be amazing.
This would help to write almost no overhead frameworks or smal shims for service worker code which could run in browsers and nodejs with no changes, which would be awesome :-)
Activity
bmeck commentedon Feb 8, 2022
Service Workers use cases seem a fine to hope they match, but various things like having a HTTP cache implementation as the means of controlling things like
file:URLs likely won't match up in implementation. Additionally, service workers have a concept of origins that doesn't make as much sense on the backend and prevent seeing cross origin requests.Loader use cases are more complex, but we do have some insurance that the model can be emulated in the web and vice versa with proof of concepts we generate every so often so we do consider compatibility but not design important.
A polyfill of
ServiceWorkeron top of --loader is possible by injecting a global during globalPreload and then having the loader spin up a worker. I think having some ship for it would be good but I doubt it would land in Node's core anytime soon, certainly not before loaders are fully stabilized.frank-dspeed commentedon May 20, 2022
@bmeck i also invested into the serviceWorker concept and i guess it is importent to have it including the origin level while that is blocking and looking like none sense in first case out of my view it would help to algin the ecosystems as also would enable some really nice extra usecases
Explainer Web Worker API (Concept)
i vote for a complet serviceWorker implementation as also bind it to a Web Worker Specification so a NodeJS WebWorker will offer fetch (the full spec) including the context like location as web workers do it in the browser and finally this web workers would be able to instantiate service workers
the browser got a so called activation api to init the service worker and directly activate it via api without page reload this will be the standard behavior of the node implementation
and finaly we did it we enabled nodejs users to run stuff in a isolated by url context.
and also made clear that this is not needed for none web development
the web worker will also expose Web Streams and Web Crypto directly it will be like the browser implementation of it
the configuration of the Web Worker new webWorker() will offer configuration options for the cache and the whole policy headers.
loader related alternative
register the service worker via a loader and then this service worker will only work for the nodejs Web Worker API if the context matches.