msw in a module federation setup

[koengsen]

I have a small setup with webpack module federation, one container app and one remote. The remote is exposing itself completely and the container is consuming it to show it after clicking a navigation link like /users.

The container is reachable at localhost:8080, the remote at localhost:3001

Now, the remote is using mockup service worker, which works fine when visiting the app directly. When called through the container, an error comes up:

Uncaught (in promise) Error: [MSW] Failed to register a Service Worker for scope ('http://localhost:8080/') with script ('http://localhost:8080/mockServiceWorker.js'): Service Worker script does not exist at the given path.

I also tried setting the scope with

worker.start({
  serviceWorker: {
    options: {
      scope: "http://localhost:3001",
    },
  },
})

which resolves in an error

Failed to register a ServiceWorker: The origin of the provided scope ('http://localhost:3001') does not match the current origin ('http://localhost:8080').

Does anyone have experiences with this? Using service workers in remotes with module federation? How to call them in the container?

[kettanaito]

Hi, @koengsen.

I'm not familiar with module federation but I'm certain that if you're making an HTTP request in your container (localhost:8080), then in order to have it intercepted and mocked by MSW you must have the worker registered and active on the same host (container's host). In other words, if you see the /users call in your container's Network tab in DevTools, you need a worker to intercept that.

Could you try generating two workers—one for your remote and one for your container?

npx msw init ./container/public
npx msw init ./remote/public

You can also copy the mockServiceWorker.js file by any other means.

You'd have to follow with the same setupWorker setup in your container it seems.

Module federation support is not present at the moment, but we'd love to use this opportunity to learn more about what it'd mean for the library. For instance, I'm curious how exactly the remote is exposed to the container? Is it some sort of proxy?

[patel-jeel92]

Has there been any updates on this? Currently, I have duplicate mock services workers for different micro apps(remotes) that live in the remote and in the container app. If there is a way to share the different mock service workers of different remotes via module federation, then that would avoid duplication

[kettanaito]

@patel-jeel92, no update on this. You are welcome to explore this and if we can support you on the library's side we'll surely will. There's no drawback to generating and keeping multiple service worker scripts—treat those as build artifacts. You don't duplicate any logic by having multiple scripts, you only have to ensure all of them are updated when you update the library (you can use msw.workerDirectory in your package.json for that like here).

[cliffordfajardo]

There's is also a discussion here, referencing for context & also potential for folks to add on the conversation

• Single-SPA 2 applications example #380 (comment)

[patricklafrance]

We got this working with MSW v1 (I am bit late as it seems like v2 will be released next monday 😅).

It's not that complicated, but you need to be set up properly to make it work. The idea is that your remote modules should be provided a mecanism to register their MSW request handlers with the container application. Once all the remote modules are done registering their request handlers, then the container application can start MSW with the provided request handlers.

To do this, we managed to get all our remote modules to expose a register function. We dynamically load our remote modules but it should also be possible to do it with the exposes field of ModuleFederationPlugin:

{
    plugins: [
        new ModuleFederationPlugin({
            name: "remote1",
            filename: "remoteEntry.js",
            exposes: {
              "./register": "./src/register.js"
            }
        })
    ]
}

With that register function, the remodule modules can register their request handlers with the container application. Let's say that you have a mocks/handler.ts file with a single request handler:

import { rest } from "msw";

export const requestHandlers = [
    rest.get("/api/character/1", async (req, res, ctx) => {
        return res(
            ctx.status(200),
            ctx.json([{
                "id": 1,
                "name": "Rick Sanchez",
                "status": "Alive"
            }]);
        )
    })
];

In your register function you can do:

export async function register(requestHandlerRegistry) {
    if (process.env.USE_MSW) {
        const requestHandlers = (await import("./mocks/handlers.js")).requestHandlers;
        
        requestHandlerRegistry.add(requestHandlers);
    }
}

When the container application is bootstrapped, do the following:

• Create a requestHandlerRegistry instance
• Retrieve all the remote modules register functions
• Call all the register functions with requestHandlerRegistry as an argument and await them.
• Once every remote module is registered, start MSW with the registered request handlers:

if (process.env.USE_MSW) {
    import("./mocks/browsers.js").then(({ startMsw }) => {
         startMsw(requestHandlerRegistry.handlers);
    });
}

Sorry there are a few missing steps, but such a setup involves many parts. Our custom application shell code and documentation is open source if you are looking for additional information or inspiration: https://gsoft-inc.github.io/wl-squide.

This section is showing how to do it with our custom application shell: https://gsoft-inc.github.io/wl-squide/getting-started/learn-the-api/#mock-service-worker

I hope that will still work with MSW v2 🤞🏻

[atulpatildbz]

thanks for this.
were you able to achieve this with MSW v2?
Also i have a special case where one of my MFEs will keep using MSW v1. but others will be using v2.

I may spend some time this week to try out these scenarios as well

[patricklafrance]

Yes it works the same with v2

[lobaak]

This helped us figure out a solution. Many thanks!

[goldsam]

Is there a technical constraint inherent to service workers that would preclude handlers from being registered after msw was started? The correct approach IMHO, would be for each lazy-loaded micro-frontend to register its handlers when it gets bootstrapped. Requiring that developers eagerly load and bootstrap handlers for ALL micro-frontends would add a tremendous amount of needless complexity and undermines the motivation for using microservices in the first place.

[kettanaito]

Is there a technical constraint inherent to service workers that would preclude handlers from being registered after msw was started?

No, not at all. You've been able to add request handlers after the worker has started for years now via the worker.use() API.

Requiring that developers eagerly load and bootstrap handlers for ALL micro-frontends would add a tremendous amount of needless complexity and undermines the motivation for using microservices in the first place.

This sounds like a handler organization issue more than how you initiate MSW. I may be missing federation-specific context, but I'd expect you have a bunch of projects each calling setupWorker() with their handlers, then await worker.start(). When the app loads, only one instance of the worker will be registered, all the other worker.start() calls will reuse the existing worker registration but will have their own list of handlers to handle the traffic.

[goldsam]

@kettanaito I was missing that worker.start() could be called multiple times and the the results were additive. Also, thanks for pointing out the use method. 😉