How to bypass requests on the worker level?

[jkieboom]

Scope

Adds a new behavior

Compatibility

• This is a breaking change

Feature description

We are running our tests currently on AMD which means loading lots of javascript files. When the service worker is active, each single request requires a round trip to the main thread and back just to say that certain urls should passthrough. This adds significant latency in our case (test run time increases 3x in certain cases).

I did a quick proof of concept of having an exclude list of urls directly in the service worker so it can opt out of handling those urls entirely. This resolves the latency issue we're seeing.

It would be nice if there was functionality where we could configure the worker with such a list of url prefixes.

[kettanaito]

Hey, @jkieboom. Thanks for raising this.

I understand the extra journey to the worker and back may have implications like latency but it's rather challenging to circumvent it entirely. When using MSW, the request flow is:

1. Request client dispatched a request;
2. Request hits the Network;
3. Request hits the "fetch" event of the worker;
4. The worker signals request info to the client;
5. The clients responds to the worker on what it should do with the request;
6. The worker proceeds with the request (either mocks it or bypasses it).

We cannot skip points 2 and 3 because the client won't be able to know anything about the request then.

The whitelist of endpoints is data. The only way to pass the data to a worker is by posting a message. Posting a message is an asynchronous action, which means we introduce a window of uncertainty while it's being processed. In this light, even if we added something like

worker.start({
  whitelistHosts: ['api.github.com']
})

we would have to send that whitelist data to the worker upon its start. To prevent intermittent behaviors, we'd have to await the worker to receive that data, which means a window during which no requests can be handled. Now, we have the same latency applied to every request anyway.

The most sensible way here is to compose workers, I think. You can have your custom worker that imports the MSW's worker via importScripts() but has some whitelisting logic built-in into itself that short-circuits the request processing before it hits the MSW worker. The issue with this is that you always end up with Request -> Worker -> Request journey no matter which context holds the whitelist data. It'd arguably have to be faster since there's no messaging back to the client, so you may give this a try.

// public/whitelistWorker.js
const whitelistHosts = ['api.github.com']

self.addEventListener('fetch', (event) => {
  const url = new URL(event.request.url)

  if (whitelistHosts.includes(url.host)) {
    // Do not propagate this event to other listeners (from MSW).
    event.stopImmediatePropagation()

    // I'd expect this early return to take precedence
    // over the MSW logic below, allowing you to
    // bypass it entirely, releasing the request.
    return
  }
})

importScripts('./mockServiceWorker.js')

[jkieboom]

we would have to send that whitelist data to the worker upon its start. To prevent intermittent behaviors, we'd have to await the worker to receive that data, which means a window during which no requests can be handled. Now, we have the same latency applied to every request anyway.

This whitelist would be setup only once on start, so instead of paying the latency for every single requests we just pay it once. We already have to wait for the worker to start anyway, so I'm not really seeing the problem.

I will try the worker wrapping.

[kettanaito]

The difference is that we are waiting for the worker because this is how the workers work. Waiting for a custom whitelist is the wait we introduce intentionally.

Do you happen to have some metrics of the latency you're experiencing? Numbers can help us decide on the best approach.

[jkieboom]

The difference is that we are waiting for the worker because this is how the workers work. Waiting for a custom whitelist is the wait we introduce intentionally.

Sure, but this is purely opt-in and I don't really see why this is a problem. I understand this will not pay off for isolated tests, but in our case we may load lots of small files (js, css, fonts) that all have to pass through the service worker.

Do you happen to have some metrics of the latency you're experiencing

I'm not sure what kind of numbers you need. In the specific case I'm looking at tests went from 1s runtime to 3s. Service worker round trips look like 16ms per request.

[kettanaito]

I'd rather approach the problem than its side effects. The problem here is the latency, so we need to analyze when exactly it happens. Messaging between the client and the worker is pretty much instantaneous, so perhaps we can optimize the nature of the messages or their handling to be more efficient.

Service worker round trips look like 16ms per request.

I suppose you feel that latency because it's multiplied by the number of tests you have?

[kettanaito]

I'm in for any solution if it keeps the established promises the library makes. That being that request handlers is the only way to affect request resolution. If we introduce a custom option that's implicitly handled by the worker, we now have two surfaces to affect how requests are resolved. I'd be against that.

But, as I've said, the whitelist proposal is here on the premise that the worker round trip is the issue. I suspect the message processing would take the most time from that.

[jkieboom]

The most sensible way here is to compose workers, I think.

I looked a bit into this, but I'm not sure how this could work. From what I can tell there isn't a way to say the worker should not handle the fetch event but at the same time no other event listeners should handle it either.

[kettanaito]

Fetch event should be handled as any other event: it can have multiple listeners and you can prevent its propagation up the listener's chain. I'm rather sure that composing workers would work. Have you set up some repo to try this out? We can collaborate on that and see for ourselves.

but at the same time no other event listeners should handle it either.

If you handle the fetch event the worker shouldn't continue with other fetch listeners since handling it multiple times is a no-op. We may get an exception in this case or the worker may treat this gracefully, I have no answer here.

[jkieboom]

Thanks for the explanation, I'm quite new to service workers. I've did a little test with a wrapper like you suggested, event.stopImmediatePropagation() can be used to stop further processing and let the request go through over the network. For me this is all good and we can close the discussion. Thanks for the detailed help, much appreciated!

[kettanaito]

Glad to hear it worked!