Msw: Question: What is your recommendation to use msw for a demo that runs in 'production'?

[ff6347]

Hi.

We are working on a React application that we want to host with a demo mode where it never should it the actual API. Since the documentation states not to use the service worker in production I have the following questions:

• Can you elaborate what the reason for this is?
• What would you recommend as an alternative?

[kettanaito]

Hello, @fabianmoronzirfas!

The docs emphasize on not including the worker in production to prevent mistakes of people deploying mocked API to their customers' machines. Service Worker is something you have to maintain once it ends up on the client's machine.

With MSW we are talking precautions for the situations when somebody deploys the worker accidentally (or not). For example, the worker self-unregisters itself when the last client (browser tab) that it controls is closed. This means that once you deploy the code that no longer activates the worker (worker.start()) the currently active workers will get stale and unregister themselves.

You can decide to ship msw in production and, moreover, some educational applications are already doing so. Just bear in mind that once you do, the worker ends up on your users' machines and it becomes your responsibility to manage it from this point.

I'd like to ask you what kind of demo are you talking about? Is it the app or its part you'd like to showcase?

[ff6347]

Hi @kettanaito thanks for the swift reply.

We are running an application that allows citizens to track if they water trees here in Berlin. Since we also have an exhibition space we want to showcase it on a large touch table without having a user account and without visitors adding information to our DB while playing around with it.

The idea I had was to mock all interactions with Auth0 and our API when running the application on a subdomain of https://giessdenkiez.de

If I understand service workers right, having it only in the build when deploying to demo.giessdenkiez.de should not affect the 'production' version.

I also want to guard the call of worker.start() by enclosing it into something like

if (process.env.BUILD_TARGET === "DEMO") {
    worker.start()
}

once you do, the worker ends up on your users' machines and it becomes your responsibility to manage it

I'm fairly new (not saying a total noob with service workers. What are the problems I could run into?

[kettanaito]

If I understand service workers right, having it only in the build when deploying to demo.giessdenkiez.de should not affect the 'production' version.

You understand it correctly. The worker will control the current location, which in your case would be demo.giessdenkiez.de. It shouldn't affect other subdomains, or the root domain.

From what you've shown here it looks pretty safe to deploy the worker for the demo purposes. The safeguard is also a great way to describe what happens and why, so 👍 here.

I'm fairly new (not saying a total noob with service workers. What are the problems I could run into?

Let me describe some of the default behaviors of Service Workers. Note that some of them won't apply to the full or partial extent when using the worker from MSW.

• Worker that's already registered on the remote machine will not get unregistered/updated if you push the next version of the worker. This makes it difficult to propagate changes to the mocked API to the controlled remote machines.
• Service Worker API implementation may differ across browsers. While you use MSW as a dev tool and can switch to a different browser need be, your customers expect to browse your product on the browser of their choice. This difference in spec implementation may result into distorted experience for the customers.
• Since Service Worker controls the network, if there's an issue in the worker itself it can bring down your application. Add here the difficulty of updating the worker, and this can be a serious incident.

As I've mentioned, we introduce a few adjustments to the worker on the library's side (for example, that the worker will unregister itself), but I still strongly recommend you to test how your application behaves once you deploy the worker. Start by testing on your local machine, before promoting the demo and, thus, registering the worker for your customers.

Also, if you're planning to showcase the application on a designated machine (i.e. a touchscreen hardware on an exhibition), and aren't planning to send the demo website to customers directly, that minimizes any possible issues to just that exhibition hardware.

In any case, don't be afraid, I think it's a great idea to have for an awesome demo. Looking forward to hear how it goes!