Our RemoteHttpResolver/RemoteHttpInterceptor API relies on the IPC between the parent and the child processes to work. This is sufficient in some cases but there are scenarios when two processes cannot establish IPC even if they seemingly have the parent/child relationship (e.g. frameworks may spawn processes in a way that won't be associated with your test parent process).
In that regard, a WebSocker-based remote interception is a much more versatile solution. I've implemented a proof of concept for it in here:
I think it can be implemented in Interceptors instead, using a similar resolver/interceptor relationship as we have right now, just swapping the IPC mechanism with WebSocket events.
Keep in mind
Interceptors are more "transparent" than MSW, in the sense that Interceptors don't introduce A) request matching; B) request resolution layer. You can affect the request resolution via request.respondWith() but it's done on a per-request basis rather than a list of "handlers" like MSW has.
This means that the underlying implementation of this feature would differ slightly from the one I've prepared in MSW (i.e. cannot "await" remote handlers before running the direct ones). This most likely implies that the .untilIdle() promises we have on request listener calls would have to stretch outside to await the request listeners being called in a remote process (basically, awaiting a WS event that indicates that).
Our
RemoteHttpResolver/RemoteHttpInterceptorAPI relies on the IPC between the parent and the child processes to work. This is sufficient in some cases but there are scenarios when two processes cannot establish IPC even if they seemingly have the parent/child relationship (e.g. frameworks may spawn processes in a way that won't be associated with your test parent process).In that regard, a WebSocker-based remote interception is a much more versatile solution. I've implemented a proof of concept for it in here:
I think it can be implemented in Interceptors instead, using a similar resolver/interceptor relationship as we have right now, just swapping the IPC mechanism with WebSocket events.
Keep in mind
Interceptors are more "transparent" than MSW, in the sense that Interceptors don't introduce A) request matching; B) request resolution layer. You can affect the request resolution via
request.respondWith()but it's done on a per-request basis rather than a list of "handlers" like MSW has.This means that the underlying implementation of this feature would differ slightly from the one I've prepared in MSW (i.e. cannot "await" remote handlers before running the direct ones). This most likely implies that the
.untilIdle()promises we have on request listener calls would have to stretch outside to await therequestlisteners being called in a remote process (basically, awaiting a WS event that indicates that).