Service workers can function as proxies and man in the middle all requests, they are very different from traditional background tasks in the general sense of the word.

The same applies for the term "demon" in Linux, "services" in Windows. I'm pretty ok with the term "service worker" as I learned, it's a background service doing background things :)

Technically it's 'deamon', not 'demon' :)

Interesting read: https://man7.org/linux/man-pages/man7/daemon.7.html

You mean daemon, not deamon or demon

Matt Damon:)

Whoops lmao

daemon? :)

Not an experienced JS dev here - if that is the case, then what is the difference between a "service worker" and a simple async function running in the background?

There are a lot of differences:

1. Service worker lifetime is not tied to a particular window. They can live across multiple windows either at the same time or across time. (Think of a tab closed then later reopened.) A background function will stop running when the tab is closed.

2. Service workers have some ability to intercept network requests. In a page you could patch APIs like fetch and XMLHttpRequest but you have no ability to intercept image loads or top-level navigations.

3. Other APIs such as receiving push notifications are also tied to service workers (likely because of the lifetime restrictions, otherwise the browser would need to decide which tab to deliver a notification to or open a new one if none are open).

If you want to intercept and modify a incoming json response for some specific url pattern, would a service worker be a good way to do so?

To illustrate, assume I frequently browse a blog and want to trick my browser into thinking that I have "favorited" every post. It's trivial to write a for loop that iterates over response.json and sets `is_favorite = true`. But it's not as clear to me where this script should ideally live in order to have the logic always executed before the response is made available to the site.

Your comment made me think about whether I can replace my overkill solution (https://requestly.io/) with something lightweight.

I don't think this will work well as a third party. Since service workers are so powerful they are quite tricky to get set up. You would need to serve it from the domain of the page that you want to intercept. You are probably much better off using a user-script or browser extension for this. I think both provide APIs for request interception but for your use case it may be easier to wrap and intercept the `fetch` or `XMLHttpRequest` API.

> If you want to intercept and modify a incoming json response for some specific url pattern, would a service worker be a good way to do so?

Yes but in this case you would need to setup a reverse proxy so your service worker and the intercepted page runs in the same domain. You could use cors-anywhere[1] for that.

[1] https://cors-anywhere.herokuapp.com/

Requestly founder here. If this is a third-party site then you don't have control over the behaviour of service worker.

Your bet is to use a browser extension to override the response of that specific API and sort of change the response.

PS - Why do you think this is an overkill solution?

> PS - Why do you think this is an overkill solution?

Only because my use case is very trivial and does not require most of the features. On the other hand, it did get the job done on the first try so I can't really complain.

Simple async JavaScript is still single threaded with an event loop. In other words, your async code is just a task deferred for later and only one task runs at a time, only moving onto another task when complete or explicitly yielding via “await”.

Service workers are threads. They’re basically separate JavaScript processes you communicate with with IPC, with other special privileges and capabilities allotted to them.

Service worker is a whole pattern to give PWA's offline access, ie. intercepting network requests and caching. Async runs on the main thread. If you want to offload work to another thread you use a webworker.

To my understanding service workers are run in a separate thread using the Web Worker API, and thus are non-blocking unlike standard async functions.

promiscuous terminology :)