Open KenjiBaheux opened 9 years ago
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?
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.
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:
WDYT? Maybe this has been discussed before, let me know.