Why we built Clinic 🏥 w/ Botox 💉— a reverse proxy management platform

Clinic Version 1.47.32

Why were Clinic and Botox needed?

There was a point in time @DollarShaveClub where we had 11 micro frontend services that required their own processes and ports. This presented some major challenges to our development process.

For example, if you wanted to implement and test a feature for /cart. The typical development flow was to:

1. Run /account service to be logged in, and then
2. Run/storefront service to modify items and then
3. Run /cart/ service to be able to manage the cart
4. … etc run any other services that were needed

As you might imagine, a lot of time was lost to discoverability to get the proper scopes and flow running. And if one service wasn’t working — then the entire development flow was broken.

Why 11 micro frontend services in the first place?

The driving factor in breaking up our React applications into separate repos was to reduce bloat as the site grew in scale, an issue we experienced with Ember prior to our migration to React. We had also yet to venture into monorepositories. We’d encourage scope isolation so that you can’t break other services when developing, however this was very cumbersome and bottlenecked our deploy train frequently.

What does Clinic and Botox do?

At a very high level — Clinic is our UI to Botox which is a reverse-proxy for porting local requests to our QA, Release, and Production servers. This allows for Frontend to access backend APIs without having to run the backend services locally.

For example, when you start Clinic it will start up a node server. In order to visit all our services, our requests will have to go through that node server. Botox will have a predetermined list of ports and paths that map to our local frontend apps and will start automatically proxying your requests to your local frontend service.

Sample of what our botoxConfig would ideally look like:

const botoxConfig = [
  {
    path: '/api',
    proxy: {
      target: 'https://www.dollarshaveclub.com',
    },
  },
  {
    path: [
      /^(\/$|\/\?)/i,
      /^\/account(.*)$/i,
      /^\/get-started(.*)$/i,
      /^\/gift(.*)$/i,
      // ...remaining frontend routes
    ],
    proxy: {
      target: 'http://localhost:3573', // Local React App
    },
  },
]

So instead of having to start n-number of services like before, we just have to start the 1 frontend service and proxy the backend services.

This gives us flexibility to quickly add/remove different services, develop in different shops such as au, ca, uk and context-switch between release and production environments rapidly.

Here’s a lengthened diagram of the entire process.

What benefits have we seen and how have we scaled Clinic?

1. Reduced the onboarding time of an engineer from the time they’re able to fully set up dev environment and make changes in prod from 1 week to less than 1 hour.
   - No more need to run all services. No more dealing with fragile dev environments where a bug usually requires a senior engineer to support.
2. Massively reduce the load of running many services on your computer.
   - We initially used Vagrant to run all of the services as containers so that we didn’t have to worry about configuration and that everything was containerized. Problem was we were consuming 8 gigs of memory. It wasn’t developer friendly and was also killing your machine.
3. Flexibility to scale. Clinic is an electron app, which allows us to layer additional features such as using it as our main incident command tool where you can draft incident emails and manage on-call schedules.

Incident feature of Clinic

What vision do we have for Clinic?

The vision for Clinic is that it gets an engineer from 0 to 100 very quickly in setting up their dev environment and serves to be an all-in-one platform to create development enhancing features here at DSC.

Thanks to the Engineering team at Dollar Shave Club who have helped supported this tool and article. Shout-out to Jacob Kelly and Dan Benson 🎉