feat(service-worker): Support ignoring specific URLs

[aSegatto]

🚀 feature request

Relevant Package

This feature request is for @angular/service-worker

Description

While forcing the SW to ignore specific URL is now possible adding http header ngsw-bypass or ngsw-bypass=true as query param, it's not possible to specify some URLs to be ignored. This would be very useful when dealing with SDKs like Firestore, that don't allow to edit the http requests.

Describe the solution you'd like

As discussed in #21191 some workarounds are possible : #21191 (Comment) or 21192 (Comment).

Second comment also contains a suggestion on how to modify SW in order to implement the requested feature. This would mean accepting messages to allow to set a list of URLs to ignore.

[petersalomonsen]

As mentioned in #21191 (comment) I would try intercepting. If intercepting using https://angular.io/api/common/http/HttpInterceptor or the example with XmlHttpRequest does not work if Firestore is using the Fetch api, I believe it should be possible to intercept the Fetch api too.

Posting a map of URL's may not be sufficient either as in some cases you don't know the URL, because it's given to you as a response from another call. An example is one of my own use-cases where I'm using git for offline storage in the browser and git LFS for dealing with large files. To get the upload URL (which I want the serviceworker to bypass), I need to make a post request first, which returns the upload URL. You can see where it happens here: https://github.com/fintechneo/angular-git-filebrowser/blob/master/src/lib/gitbackend/gitbackend.service.ts#L898

In this case it's easy for me to send headers, either by intercepting or modyfing the library itself of course, but a URL map wouldn't help much. Also when introducing URL maps, you'd probably soon discover that just matching URL's isn't enough. You'd want to match URL patterns, which method is used etc. We'd end up with lot's of logic in the serviceworker for handling this, while it could probably be solved more easily in the client. In the client code you can have tailored code for intercepting and checking requests.

Thinking out loud, there's a another alternative: instead of sending a map of URL's to bypass, you could send function code to the serviceworker that it should use to check the requests. I haven't thought through what side-effects that could cause, but it would at least give you full control over the logic for bypassing the serviceworker. @aSegatto @gkalpak

[aSegatto]

I thought that sw had already some sort of glob logic, to know how to handle data api requests but if it has not, i agree it's a lot of work to do ... maybe just adding or removing urls dynamically from the map in the sw could do the trick, but of course you need to know the exact url.

Sending a function to the sw is very powerful, but i think wouldn't be considered a good practice by many as you should eval code on the fly.

[gkalpak]

Yeah, sending a function for the SW to evaluate is probably not a good idea 😁

To recap:

The decision about whether to handle the request or not has to be made in a way that does not violate the following assumptions:

1. The decision is made synchronously.
2. The SW script remains independent of the app version.

One way to achieve this is by making the decision on the app side and communicating it to the SW via some form of metadata embedded into the request itself (e.g. custom query param or header - this is already supported). This will work in cases where you can control the URL/request, but there are still cases where this isn't possible (which is what this issue is about).

[petersalomonsen]

So this is where one probably could consider adding "SDK features" to the serviceworker module, so that it would be possible to compile your own ngsw-worker.js for plugging in URL exceptions like requested here, and / or other serviceworker features (e.g. if you want to use it for any of the use-cases described here: https://serviceworke.rs/).

This would maybe involve additions to the CLI, and also is much about documentation (serviceworker cookbook).

Is that an idea?

[petersalomonsen]

Another idea:

Add property in ngsw-config.jsonpointing to a .js file containing app-specific code to be executed in the serviceworker (onFetch event). That would be a simple but powerful addition that keeps the SW script independent of the app version, and does not involve code evaluation on the fly.

[gkalpak]

WRT #30195 (comment):
Although there are no immediate plans, we are considering/investigating ways to make the SW more flexible and extensible. It will take a significant refactoring, though, so not going to happen overnight 😁

WRT #30195 (comment):
Anything involving ngsw-config.json is async (i.e. the SW needs to retrieve the config from the Cache) and thus can't be used to make a sync decision in onFetch.

[angular-robot]

Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

Find more details about Angular's feature request process in our documentation.

[angular-robot]

Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.

We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.

You can find more details about the feature request process in our documentation.

[gkalpak]

Given the relatively low demand for this feature and the fact that there doesn't seem to be a good solution (that doesn't require a SW re-write 😁), I am going to close this.

For anyone that absolutely needs this with the Angular ServiceWorker, there are the work-arounds referenced in the issue description (such as #21191 (comment)). The more generic feature of making it possible to extend/modify the ServiceWorker logic is being tracked in other issues; in particular #21197 (and also #24387 and #26413 for the specific case of overriding push handling).

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}