Common challenges
Environments

Environments (how to safely access production data)

Often the build you have locally uses different environment variables to production. This is particularly relevant for your database connection.

Strategy 1 (dangerous)

The simplest strategy is to connect to the production database for replicating this request.

You know your app best. This can be suitable if there's no global side effects (e.g. an Express server where nothing substantial runs outside of the endpoints you hit).

⚠️

While you know your app best, this can obviously be dangerous!

Strategy 2 (read-only)

This takes more config, but you can set up a read-only user on your production database.

So you run your app locally, but pass an environment variable etc. to swap your connection-string.

This lets you easily and safely reproduce any request that involves reading data. You can also do things like this:

async function save(obj) {
    if (process.env.DATA_MODE === 'readonly') { // whatever flag you use
        console.log('read-only mode. Would have saved', obj);
    }
}

If you use stores or ORMs, you might only have to implement this in a small number of places.

This lets you re-run requests, and look at what would have happened, without actually changing anything.

You might need to do something similar for other writes or side-effects (APIs, filesystem, etc.)

Strategy 3 (clone)

You can clone your production database to a local database. Or a relevant section. This is the most work on a per-request basis.

⚠️

Beware of side-effects, e.g. sending emails to real users, API calls, etc.

Recommendation

It's often worth setting up a read-only user. It's really nice being able to iterate, experiment, step through things in a debugger, etc. So the best option is often Strategy 2.