A way to hand off in-scope network requests to a third party's Service Worker

[KenjiBaheux]

If I understand correctly, a client site would have to use postMessage to send API calls to a third party. For third parties with existing REST API, wouldn't it be better if the client had the ability to let that third party's service worker handle the relevant (third party's origin and in-scope) network requests?

Use Case: Site A is using the analytics service of Third Party B. The integration merely consists of including B's javascript code via a script tag.

Naively, here is how it could work:

1. When B's javascript code is executed on Site A, it calls navigator.connect(https://api.b.com/v1/sw.js).
2. Maybe that call alone makes the user agent to turn B's Service Worker as in control of https://api.b.com/v1/* network requests or maybe there is an additional parameter or an extra method to call to make that happen.
3. From there on, Whenever network requests are made to the https://api.b.com/v1/ API endpoints, B's service worker is asked to take care of them.
4. This in turns enable offline support, smarter logic, background sync for batch processing/updates... for user agents that support SW and navigator.connect. Also, A doesn't have to change its integration. B doesn't have to duplicate its existing API to a postMessage based approach.

WDYT? Maybe this has been discussed before, let me know.

[jakeleichtling]

This sounds very similar to the universal look-aside fetch() approach that Mozilla suggested, where all network requests to endpoints in the https://api.b.com/v1/ are handled by B's SW if it is installed, passing straight through to the network if it is not. The difference in your proposal seems to be that Site A needs to at some point use navigator.connect(https://api.b.com/v1/sw.js) to confirm that B's SW should handle these network requests by default.

My understanding is that the primary advantage of the universal look-aside fetch() is that it will automatically connect to B's SW when appropriate, without any changes on A's part; and that one of the primary advantages of the MessagePorts approach is that the communication with B's SW is explicit. I'm having trouble seeing the advantage of this proposal (calling navigator.connect to initiate the look-aside fetch() behavior) as it seems to detract from both the automatic uptake of the universal look-aside fetch() approach and the explicit nature of the navigator.connect() MessagePorts approach. Could you help me understand the advantages of the hybrid approach?

[jyasskin]

Yeah, I think having the target SW declare a scope in which it will intercept subresources, dominates the approach where you call navigator.connect() to direct subresources to the target SW's normal scope.

The intercept-subresources approach allows the target SW to optimize things even without the client site having a SW, and if the client wants to avoid the target SW, they can write their own SW that intercepts the resources first.

I kinda think we should do both. Maybe we can explain subresource interception in terms of messages posted across a navigator.connect channel? This is tricky, though, unless the source does explicitly opt into the interception.