Web Demos

Problem Statement

Years ago, while working as a frontend developer with teams where the backend developers could not keep pace, I realized the importance of providing fake backend endpoints to call. These fake endpoints allowed me to progress my work, and more importantly, define the interface via an OpenAPI specification. I needed the endpoints to represent different data scenarios that I could use to exercise the edge cases in the browser. At the same time, our users needed a way to provide quick feedback on different user flows during development.

Solution 1 (2018)

During the development of frontends, I built a NodeJS service for each frontend to handle different data scenarios and provide the fake backend endpoints. Each frontend and its accompanying service was deployed to an environment as a demo for stakeholders and business users to provide feedback. The demos were deployed to a Kubernetes cluster and were automatically deployed through CI/CD pipelines in GitLab.

The demos provide different links for each data scenario using a URL slug in the following format:

https://{host}/{scenario_slug}/-/{route}

The scenario_slug was extracted in an ExpressJS middleware and cached in the request state. The request was then processed as usual with the extracted scenario to switch different datasets. The frontend was then provided with a base tag, so that the frontend would build all paths relative to the base.

<base href="/{scenario_slug}/-/" target="_blank">

Some of the standard scenarios we began to implement in each of our frontends were:

Scenario	Description	Purpose
No Data	The result returned no content in the body.	Assess the app behavior with no data
Default	The default sample of data provided by the consumer.	Assess the “normal” app behavior
Small	The result returned a small, generated sample of random data.	Assess the performance and the real estate handling
Medium	The result returned a medium, generated sample of random data.	Assess the performance and the real estate handling in the browser
Large	The result returned a large, generated sample that reaches the expected limit of future production data.	Assess the performance and the real estate handling in the browser
Extra Large	The result returned an extra large, generated sample that doubles the expected limit of future production data.	Assess the performance and the real estate handling in the browser

The scenarios could be extended to any arbitrary dataset to meet customer needs and edge cases to test. Some of the scenarios require backend compute, such as simulating slow traffic to verify loading spinners to optimize the user experience. The scenarios are an incredibly powerful way to build frontends. They allow the frontend developer to build their solution without the availability of the rest of the stack. The development team can still collaborate on the interface, specification, and requirements.

Solution 2 (2026)

I learned of the Mock Service Worker MSW through the The Frontend of the Computer episode of Oxide and Friends. Since I was already using NodeJS to provide a middleware to parse the scenario and provider handlers, it was relatively straightforward to leverage the MSW in the browser.

The primary change was moving the scenario_slug into local storage.

Using MSW has improved frontend development in multiple ways:

1. Frontend developers no longer need to manage docker images. a. Reduction in Technical Debt: They do not have to set up a docker image build or maintain a Kubernetes demo namespace. They no longer have to manage chaining CI/CD pipelines in GitLab to automate the delivery of the demos. b. Reduction in Security Debt: They no longer have to deal with cloud vulnerability scans of docker images over time.
2. The frontend demos are now deployed to a static web server. The static web server itself is running in Kubernetes as an Nginx reverse proxy to Azure blob storage, but the frontend developers can simply deploy their frontend assets and their mock service worker code to blob storage.