Hacker News Reader

Comment by kevincox | Hacker News Reader

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).

View on HN

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.

Reply on news.ycombinator.com