DEV Community: Sandeep Bansod

We Deployed a "Small Fix" and Took Down Production — Here's What Actually Happened

Sandeep Bansod — Fri, 17 Apr 2026 08:11:19 +0000

A minor backend change caused a production outage, high CPU usage, and API failures. Here's how it happened, what we missed, and how we fixed it.

The Incident

It started as a simple task.

"Just add one more field to the API response."

No major logic change. No risky deployment.
Just a small enhancement.

We deployed it to production… and within minutes:

API response time jumped from 120ms → 5s
CPU usage hit 95%
Some endpoints started timing out
Users began reporting failures

At first, nothing made sense.

What Changed?

Here's the actual change:

// Before
const users = await User.find({ isActive: true });
// After
const users = await User.find({ isActive: true })
  .populate("orders");

Looks harmless, right?

That .populate("orders") was the killer.

The Real Problem

Each user had multiple orders.

So instead of:

1 query

We now had:

1 query + N additional queries (for each user)

This is called:

N+1 Query Problem

With ~2,000 users:

That turned into 2,001 database queries per request

Why It Broke Production

MongoDB connections got saturated
CPU usage spiked due to excessive queries
API latency exploded
Node.js event loop got blocked

Even worse:

This endpoint was used in the dashboard
Every page load triggered this heavy query

Why We Didn't Catch It

Because:

Local data was small (10–20 users)
No load testing
No query monitoring in staging
No performance checks before deploy

Everything worked "fine" locally.

The Fix

We replaced .populate() with a controlled query:

const users = await User.find({ isActive: true }).lean();
const userIds = users.map(u => u._id);
const orders = await Order.find({
  userId: { $in: userIds }
}).lean();
const ordersMap = orders.reduce((acc, order) => {
  acc[order.userId] = acc[order.userId] || [];
  acc[order.userId].push(order);
  return acc;
}, {});
const result = users.map(user => ({
  ...user,
  orders: ordersMap[user._id] || []
}));

Result After Fix

API response time: 5s → 180ms
DB queries: 2000+ → 2 queries
CPU usage normalized
System stable again

Lessons Learned

1. Never trust `.populate()` blindly

It looks simple but can be expensive at scale.

2. Always think in queries

Ask yourself:

"How many DB calls will this line generate?"

3. Test with realistic data

Your local environment lies.

4. Add performance monitoring

Track:

query count
response time
CPU usage

5. Use `.lean()` when possible

It reduces memory overhead and improves performance.

Bonus: Safer Alternative Pattern

For large datasets:

Use aggregation pipelines
Use pagination
Limit populated fields
Cache frequently used data

Final Thought

Most production outages don't come from big changes.
They come from small changes that scale badly.

Originally published at stackdevlife.com

We Ran git rebase on a Shared Branch and Lost Three Days of Work

Sandeep Bansod — Sun, 12 Apr 2026 10:06:51 +0000

It was a Thursday afternoon. Developer 1 had been working on a feature for four days. Clean commits, good code, reviewed and approved. He was about to open the final PR when he ran one command.

git rebase main

Then git push --force.

By the time anyone realized what had happened, four developers had lost their local branches. Two PRs were silently broken. One developer's two days of work had simply vanished from the remote. The CI pipeline was green — because it was running against old commits.

We spent three days untangling it. Here's exactly what happened, why it happens, and how we recovered — so you don't have to learn this the same way we did.

What git rebase Actually Does to History

Most explanations of rebase start with diagrams. Let's start with the thing that matters: rebase rewrites commits. It doesn't move them. It creates brand new commits with new hashes that contain the same changes.

Before rebase, your feature branch's commits have specific SHA hashes — say a1b2c3 and d4e5f6. After you rebase onto main, those same commits become x7y8z9 and m1n2o3. Different hashes. Different objects in Git's database. As far as Git is concerned, those are completely different commits.

# Before rebase
git log --oneline feature/payments
# d4e5f6  Add payment validation
# a1b2c3  Add payment model
# 9g8h7i  Initial setup (base commit on main)

# After git rebase main
git log --oneline feature/payments
# m1n2o3  Add payment validation   ← new hash, same change
# x7y8z9  Add payment model        ← new hash, same change
# 3k4l5m  Latest commit on main

This is fine when the branch only exists on your machine. The problem starts the moment that branch lives on the remote and someone else has based work on it.

How the Disaster Unfolded

Here's what our team's branch situation looked like that Thursday:

main
└── feature/payments  ← Developer 1's branch, pushed to remote 4 days ago
    └── feature/payments-ui  ← Developer 2's branch, based off Developer 1's

Developer 2 had been building the UI layer on top of Developer 1's branch for two days. Her local branch pointed to Developer 1's old commits — a1b2c3 and d4e5f6.

Then Developer 1 rebased and force-pushed.

The remote feature/payments now had completely different commits. Developer 2's branch still pointed to the old ones — which now existed nowhere except her local machine and Git's reflog.

When Developer 2 ran git pull origin feature/payments, Git saw her branch had diverged from remote. She assumed it was a normal conflict. She merged. Git dutifully merged two versions of the same code — the original and the rebased copy — creating a mess of duplicate changes, phantom conflicts, and commits that referenced parents that no longer existed on the remote.

And because two other developers had also pulled from feature/payments earlier that week, their local branches were in the same broken state.

The Error That Should Have Stopped It

The actual signal was there. When Developer 1 tried to push after rebasing, Git rejected it:

git push origin feature/payments
# error: failed to push some refs to 'origin/github.com/team/repo'
# hint: Updates were rejected because the tip of your current branch is behind
# hint: its remote counterpart.

Git was saying: the remote has commits you don't have. Your histories have diverged. Stop.

Instead of reading this as a warning, Developer 1 added --force to make it go away.

git push --force origin feature/payments
# Everything up to date.  ← the most dangerous success message in Git

The push succeeded. The damage was done.

How We Recovered

Recovery took three steps. The order matters — don't skip step one.

Step 1: Stop everyone from pulling or pushing immediately

The moment you realize a shared branch has been force-pushed, message the team. Anyone who pulls will compound the damage. Anyone who pushes will overwrite the recovery.

# On Slack / Teams immediately:
# "Do NOT pull feature/payments. Do NOT push anything to it.
#  Stay on your current branch. We're recovering."

Step 2: Find the lost commits with git reflog

git reflog is Git's black box recorder. It tracks every position HEAD has been at, including commits that are no longer reachable from any branch. On Developer 1's machine — because the original commits existed there before the rebase — reflog still had them.

git reflog
# m1n2o3 HEAD@{0}: rebase finished: returning to refs/heads/feature/payments
# x7y8z9 HEAD@{1}: rebase: Add payment model
# d4e5f6 HEAD@{2}: commit: Add payment validation   ← original commit
# a1b2c3 HEAD@{3}: commit: Add payment model        ← original commit
# 9g8h7i HEAD@{4}: checkout: moving from main to feature/payments

d4e5f6 and a1b2c3 — the original commits — were still there in reflog. Git never actually deleted them. It just stopped pointing any branch at them.

# Create a recovery branch at the last good state
git checkout -b feature/payments-recovered d4e5f6

Step 3: Restore the remote branch from the recovery point

# Force-push the recovered branch back to remote
# (yes, another force-push — but this time intentional and coordinated)
git push --force-with-lease origin feature/payments-recovered:feature/payments

We used --force-with-lease instead of --force. This flag checks whether the remote has changed since you last fetched — if someone else has pushed in the meantime, it fails instead of overwriting. Much safer.

Step 4: Help teammates rebase their local branches onto the restored remote

Once the remote was restored, each developer on the team needed to update their local branch:

# Each affected developer runs:
git fetch origin
git checkout feature/payments
git reset --hard origin/feature/payments

For Developer 2, whose branch was derived from the broken state:

# Find the last good commit on her branch before the bad merge
git log --oneline feature/payments-ui
# Identify the commit just before the bad pull

# Rebase her work on top of the restored branch
git rebase --onto origin/feature/payments <bad-merge-commit> feature/payments-ui

It took about 90 minutes of careful, coordinated work. But every commit was recovered.

The Actual Fix: Never Let This Happen Again

The root cause wasn't Developer 1 making a mistake. The root cause was that the repo allowed it.

Fix 1: Use --force-with-lease instead of --force — always

--force overwrites whatever is on remote, no questions asked. --force-with-lease checks first. If the remote has commits you haven't seen, it refuses. Make this a team standard.

# Never
git push --force origin feature/branch

# Always
git push --force-with-lease origin feature/branch

Fix 2: Enable branch protection on shared branches

In GitHub, go to Settings → Branches → Branch protection rules. For any branch that more than one developer works from:

☑ Require pull request reviews before merging
☑ Require status checks to pass
☑ Do not allow bypassing the above settings
☑ Restrict force pushes          ← this is the one that prevents the whole incident

Force push to a protected branch returns an error immediately — before any damage is done.

Fix 3: The golden rule of rebase

Only rebase branches that exist only on your machine.
Once a branch is pushed and someone else might have it — merge, don't rebase.

If you want a clean linear history, use squash merge when closing the PR. That gives you one clean commit on main without rewriting anyone's history mid-flight.

Fix 4: Enable git rerere for teams doing a lot of rebasing

rerere — Reuse Recorded Resolution — caches how you resolve a conflict. If the same conflict appears again (which happens constantly when multiple developers are rebasing against main), Git resolves it automatically.

# Enable globally
git config --global rerere.enabled true

The Takeaway

git rebase is not dangerous. Force-pushing a rebased branch to a remote that others are working from is dangerous. The commands are the same. The context is what changes everything.

The rule is simple: if your branch exists only locally, rebase freely. The moment it's pushed — especially if someone else might have pulled it — treat it as immutable. Merge onto it. Squash when you close the PR.

And if it's already happened: breathe, message the team to stop, open reflog, and work backwards. The commits are almost certainly still there.

Git doesn't delete things. It just stops showing them to you.

Originally published at stackdevlife.com

ESM vs CJS — Why Your import Still Breaks in 2026 and How to Finally Fix It

Sandeep Bansod — Wed, 08 Apr 2026 13:10:42 +0000

You install a package. You import it the normal way. Node throws ERR_REQUIRE_ESM. You switch to require(). Now TypeScript complains. You add "type": "module" to package.json. Now half your other imports break. You spend two hours on Stack Overflow reading answers that contradict each other.

This is the ESM/CJS trap. And in 2026, it's still catching experienced developers completely off guard.

Here's everything you need to actually understand what's happening — and the exact fixes for each scenario.

The Root Problem: Two Module Systems That Don't Like Each Other

JavaScript has two completely different module systems running side by side:

CommonJS (CJS) — Node's original system, introduced in 2009. Uses require() and module.exports. Synchronous. Still the default in Node.js if you don't configure anything.

ES Modules (ESM) — The official JavaScript standard, introduced in ES2015. Uses import and export. Asynchronous. The default in browsers, and increasingly the default in Node.js and the npm ecosystem.

The problem: they're fundamentally incompatible at the loading level. CJS loads synchronously. ESM loads asynchronously. This means:

ESM can import from CJS packages — Node does the interop for you
CJS cannot require() an ESM package — this is a hard error, by design

This asymmetry is why half your googled fixes don't work. The direction of the import matters.

How Node Decides Which System to Use

Before fixing anything, you need to know how Node chooses CJS or ESM for each file. The rules are:

File extension .mjs  → always ESM
File extension .cjs  → always CJS
File extension .js   → depends on nearest package.json "type" field
  "type": "module"   → .js files are ESM
  "type": "commonjs" → .js files are CJS (this is the default if "type" is missing)

This is the source of most confusion. The same .js file can be CJS or ESM depending entirely on where it lives and what the nearest package.json says.

# Check what mode a specific file runs in
node --input-type=module  # forces ESM for stdin
node -e "console.log(typeof require)"  # 'function' = CJS, 'undefined' = ESM

The Five Errors You'll Actually Hit

Error 1: ERR_REQUIRE_ESM

Error [ERR_REQUIRE_ESM]: require() of ES Module not supported.
require() of /node_modules/some-package/index.js is not supported.

This means you're in a CJS context trying to require() a package that only ships ESM. You cannot fix this with a different import syntax. Your options:

// This is what you tried
const pkg = require('esm-only-package');

// Option A: Use dynamic import() — works in CJS files
const pkg = await import('esm-only-package');
// Note: this makes your function async

// Option B: Convert your file to ESM
// Rename file.js → file.mjs, or add "type": "module" to package.json
import pkg from 'esm-only-package';

// Option C: Find an older version that still ships CJS
// Check the package's CHANGELOG for when they dropped CJS
npm install some-package@2  // many packages kept CJS through v2

Error 2: ERR_MODULE_NOT_FOUND with ESM

Error [ERR_MODULE_NOT_FOUND]: Cannot find module './utils'

In CJS, Node resolves ./utils to ./utils.js automatically. In ESM, it does not. You must include the extension explicitly.

// Works in CJS, breaks in ESM
import { helper } from './utils';
import { config } from './config/index';

// ESM requires explicit file extensions
import { helper } from './utils.js';
import { config } from './config/index.js';

Yes, even if the file is TypeScript. When you compile TS to ESM, the import paths need .js extensions in your source files — TypeScript will resolve them correctly during compilation.

Error 3: dirname and filename are not defined

ReferenceError: __dirname is not defined in ES module scope

These are CJS globals. They don't exist in ESM. Here's the replacement:

// CJS-only globals
const dir = __dirname;
const file = __filename;

// ESM equivalent using import.meta.url
import { fileURLToPath } from 'url';
import { dirname } from 'path';

const __filename = fileURLToPath(import.meta.url);
const __dirname = dirname(__filename);

// Or using the newer import.meta.dirname (Node 21.2+)
const dir = import.meta.dirname;

Error 4: Named exports break from CJS packages

// This breaks with some CJS packages
import { readFileSync } from 'some-cjs-package';
// SyntaxError: The requested module does not provide an export named 'readFileSync'

// Use default import then destructure
import pkg from 'some-cjs-package';
const { readFileSync } = pkg;

CJS packages export a single module.exports object. When Node does the ESM interop, it wraps this as the default export. Named export destructuring only works if the package explicitly defines named exports in its exports field.

Error 5: Dual package hazard — the silent one

This one doesn't throw an error, which makes it worse. If a package ships both CJS and ESM (a dual package), and your app loads it via both code paths, you can end up with two separate instances of the module. Singletons break. State doesn't share. Caches are split.

// If somehow two paths in your app load the same package differently:
// path A (ESM): import { store } from 'state-lib'  → instance #1
// path B (CJS): const { store } = require('state-lib')  → instance #2
// store in A and store in B are different objects

The fix is consistency: pick one module system for your entire app and stick to it.

The Real Fix: Converting a Node.js Project to Pure ESM

If you're starting fresh or have the bandwidth to migrate, pure ESM is the right call in 2026. Here's the complete migration checklist:

// package.json — add "type": "module" and update exports
{
  "name": "my-app",
  "version": "1.0.0",
  "type": "module",
  "main": "./dist/index.js",
  "exports": {
    ".": {
      "import": "./dist/index.js",
      "types": "./dist/index.d.ts"
    }
  },
  "engines": {
    "node": ">=18"
  }
}

// Before: CJS entry point
const express = require('express');
const { join } = require('path');
const router = require('./routes');

module.exports = { startServer };

// After: ESM entry point
import express from 'express';
import { join } from 'path';
import router from './routes.js';   // note: .js extension required

export { startServer };

// tsconfig.json — TypeScript ESM config
{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",      // critical: enables ESM-aware resolution
    "moduleResolution": "NodeNext",
    "outDir": "./dist",
    "rootDir": "./src",
    "strict": true
  }
}

The NodeNext module setting in TypeScript is the key change most migration guides miss. Without it, TypeScript won't enforce the .js extensions in imports, and your compiled output will have missing extensions that break at runtime.

When You Can't Migrate: The Dynamic Import Workaround

If you're stuck in a CJS codebase and need to use an ESM-only package, dynamic import() is your escape hatch. It works in CJS files and returns a Promise.

// In a CJS file (.js without "type":"module", or .cjs)
// Using an ESM-only package like 'chalk' v5+ or 'node-fetch' v3+

async function sendRequest(url) {
  const { default: fetch } = await import('node-fetch');
  const { default: chalk } = await import('chalk');

  const response = await fetch(url);
  console.log(chalk.green(`Status: ${response.status}`));
  return response.json();
}

// If you need it at module load time, use a top-level IIFE
(async () => {
  const { default: chalk } = await import('chalk');
  console.log(chalk.blue('Starting...'));
})();

Cache the import result if you're calling it in hot paths — dynamic import() is cached after the first call, but the async overhead of the call itself still adds up.

GitHub Repository

The full repo for this article has six working examples: a broken CJS project hitting all five errors, ESM migration steps with diffs, a dual-package setup showing the hazard, and a TypeScript NodeNext config that compiles cleanly:

👉 https://github.com/Sandeep007-Stack/esm-vs-cjs.git

Each example has a broken/ and fixed/ folder. Clone it, run node broken/index.js, see the real error, then run node fixed/index.js and see it work.

The Takeaway

The ESM/CJS split isn't a bug you can patch with a Stack Overflow answer. It's a fundamental architectural difference in how the two systems load code. Once you understand the rules — CJS can't require() ESM, extensions are mandatory in ESM, __dirname doesn't exist — the errors stop being mysterious.

In 2026, the path forward is clear: pure ESM. Every major package is dropping CJS. Node 20+ backported ESM-from-CJS interop. The tooling has caught up. If you have a new project, start with "type": "module". If you have an existing one, use the checklist above and migrate file by file.

The broken import era is ending. It just requires knowing which side of the wall you're on.

If you found this useful, I write about TypeScript, Node.js, Security and DevOps at stackdevlife.com — drop a follow if you'd like more!

Originally published at stackdevlife.com

How I Fixed a Node.js API That Was Taking 15 Minutes to Return 8,000 Records

Sandeep Bansod — Tue, 07 Apr 2026 11:01:24 +0000

The ticket came in with one line: "The API is too slow."

No stack trace. No logs. Just a frustrated client and an endpoint that took around 15 minutes to return 8,000 records. Fun.

The worst part? The code wasn't even mine. Someone else had written it, shipped it, and moved on. Now I was the one staring at a Mongoose query wondering where 15 minutes were disappearing to.

Here's exactly what I investigated, what I found, and how I brought it down to around 15 seconds — without rewriting everything from scratch.

The Setup

The API was a Node.js service using Express and Mongoose, backed by MongoDB Atlas. It had a /reports endpoint that fetched records and ran some calculations for a dashboard.

Simple enough on paper. Here's what the original route looked like:

// Original route — the culprit
app.get('/reports', async (req, res) => {
  try {
    const data = await Report.find({
      status: req.query.status,
      createdAt: {
        $gte: new Date(req.query.from),
        $lte: new Date(req.query.to)
      }
    });
    res.json(data);
  } catch (err) {
    res.status(500).json({ error: err.message });
  }
});

Nothing about this looks obviously broken, which is what made it tricky. The problem wasn't the code logic — it was everything happening underneath it.

Step 1: Find Out What MongoDB Is Actually Doing

Before changing a single line, I ran .explain("executionStats") on the query. If you've never used this, make it a habit — it's the fastest way to see exactly how MongoDB is executing your query.

const result = await Report.find({
  status: 'pending',
  createdAt: {
    $gte: new Date('2024-01-01'),
    $lte: new Date('2024-12-31')
  }
}).explain('executionStats');

console.log(JSON.stringify(result.executionStats, null, 2));

This was the output that told me everything:

{
  "executionSuccess": true,
  "nReturned": 8000,
  "totalDocsExamined": 240000,
  "totalKeysExamined": 0,
  "executionTimeMillis": 874000
}

See that? totalKeysExamined: 0. MongoDB wasn't using any index at all. It was scanning all 240,000 documents in the collection just to return 8,000 matching ones. That's a full collection scan on every single request — and 874 seconds to prove it.

Step 2: Add the Right Indexes

This was the single biggest fix, and it took about two minutes to apply.

// In your Mongoose schema
const reportSchema = new mongoose.Schema({
  status: { type: String },
  createdAt: { type: Date },
  userId: mongoose.Schema.Types.ObjectId,
  category: String,
  amount: Number
});

// Add a compound index that matches the query pattern exactly
reportSchema.index({ status: 1, createdAt: -1 });

Or if you want to add it directly in the MongoDB shell without touching the codebase:

db.reports.createIndex({ status: 1, createdAt: -1 });

Why compound and not two separate indexes?

MongoDB can only use one index per query by default. If you add individual indexes on status and createdAt separately, MongoDB will pick one of them and still do extra filtering work for the other. A compound index covers both fields together in a single efficient lookup — and the order matters. Put the equality filter (status) first, range filter (createdAt) second.

After adding the index, the explain output changed to this:

{
  "totalDocsExamined": 8000,
  "totalKeysExamined": 8001,
  "executionTimeMillis": 1200
}

From 240,000 documents examined down to 8,000. That's the impact of one index.

Step 3: Fix the Aggregation Pipeline

The original code also had a pattern that I see constantly — fetching records from MongoDB and then processing them in Node.js:

// Original: pull everything into memory, then process in JS
const records = await Report.find({ status: 'pending' });

const summary = records.reduce((acc, r) => {
  acc[r.category] = (acc[r.category] || 0) + r.amount;
  return acc;
}, {});

This is backwards. You're transferring thousands of full documents over the network just to run a sum. MongoDB can do this aggregation in the database and send you back a tiny result.

// Fixed: push the aggregation into MongoDB
const summary = await Report.aggregate([
  {
    $match: {
      status: 'pending',
      createdAt: {
        $gte: new Date(req.query.from),
        $lte: new Date(req.query.to)
      }
    }
  },
  {
    $group: {
      _id: '$category',
      totalAmount: { $sum: '$amount' },
      count: { $sum: 1 }
    }
  },
  {
    $sort: { totalAmount: -1 }
  }
]);

A few rules worth knowing here:

Always put $match at the top of the pipeline. If you filter after a $group or $lookup, MongoDB has already processed every document before your filter kicks in. Filter early, process as little as possible.

Use $project to drop fields you don't need:

{
  $project: {
    category: 1,
    amount: 1,
    status: 1,
    createdAt: 1,
    _id: 0
  }
}

Every extra field is extra bytes — across thousands of documents, it adds up fast.

Step 4: Refactor the API Code

Even after fixing the indexes and aggregation, the Node.js code itself had a few more problems worth addressing.

No pagination

Returning 8,000 records in a single JSON response is never a good idea, regardless of how fast the query is. Add pagination from the start:

app.get('/reports', async (req, res) => {
  const page  = parseInt(req.query.page)  || 1;
  const limit = parseInt(req.query.limit) || 100;
  const skip  = (page - 1) * limit;

  const filter = {
    status: req.query.status,
    createdAt: {
      $gte: new Date(req.query.from),
      $lte: new Date(req.query.to)
    }
  };

  try {
    const [data, total] = await Promise.all([
      Report.find(filter)
        .select('category amount status createdAt userId')
        .sort({ createdAt: -1 })
        .skip(skip)
        .limit(limit)
        .lean(),
      Report.countDocuments(filter)
    ]);

    res.json({
      data,
      pagination: {
        page,
        limit,
        total,
        pages: Math.ceil(total / limit)
      }
    });
  } catch (err) {
    res.status(500).json({ error: err.message });
  }
});

Use .lean() on read queries

Mongoose documents carry a lot of invisible overhead — prototype methods, change tracking, virtual getters. When you're just reading data to send as a JSON response, you don't need any of that.

.lean() returns plain JavaScript objects and can make a noticeable difference at scale:

// Without lean — full Mongoose document with overhead
const docs = await Report.find({ status: 'pending' });

// With lean — plain JS objects, faster and lighter
const docs = await Report.find({ status: 'pending' }).lean();

Parallelize independent queries

The original code was running its queries one after another:

// Slow: sequential — second query waits for first to finish
const reports = await Report.find(filter);
const summary = await Report.aggregate([...]);

If two queries don't depend on each other's results, run them at the same time:

// Fast: parallel — both queries run simultaneously
const [reports, summary] = await Promise.all([
  Report.find(filter).lean(),
  Report.aggregate([...])
]);

The Results

Metric	Before	After
Response time (8k records)	~15 minutes	~15 seconds
Documents scanned per query	240,000	8,000
Indexes used	None	Compound index
Aggregation location	Node.js	MongoDB
Pagination	None	100 records/page

Is 15 seconds blazing fast? No. But with pagination in place, real users now get their first 100 records in under a second. The full 8,000-record export — which runs as a background job — takes about 15 seconds, which is completely acceptable.

What to Actually Check When You Inherit a Slow API

This is the checklist I now go through any time I land in a slow MongoDB + Node.js codebase:

Run .explain("executionStats") first — look at totalDocsExamined vs nReturned. A large gap means missing or wrong indexes.
Add compound indexes that match your query patterns field-by-field. Order matters — equality fields go first, range fields go last.
Move aggregation logic into MongoDB — stop pulling data into Node.js just to run a reduce or a sum.
Add .lean() on all read queries where you're just serializing to JSON.
Paginate everything — no route should return thousands of records in a single response.
Put $project and $match early in aggregation pipelines to reduce document size as early as possible.
Use Promise.all for independent queries instead of awaiting them one by one.

You won't always get a 60x improvement. But if someone else wrote the code and nothing was thought through, there's almost always something obvious hiding in the query patterns. Start with .explain() and work from there.

If you found this useful, I write about TypeScript, Node.js, Security and DevOps at stackdevlife.com — drop a follow if you'd like more!

Originally published at stackdevlife.com

I Used the Wrong Git Email for 2 Weeks — And No One Noticed

Sandeep Bansod — Mon, 06 Apr 2026 09:37:49 +0000

I accidentally committed 2 weeks of client work using my personal email.

No warnings.
No errors.
No clue it was happening.

I only noticed after pushing everything to GitHub.

Here's the thing nobody tells you when you start freelancing alongside a full-time job: Git has no idea you're two different people depending on which folder you're in.

I found this out the hard way.

I'd been heads-down on a client dashboard project — late nights, quick commits, shipping fast. Then one morning I opened GitHub to review a PR and noticed something. Every single commit. Every one. Author: sandeep@personal.com.

Not sandeep@work.com. Not the email the client hired. My personal one.

I had three client projects on that machine. Same story across all of them. Two weeks of commits. All from the wrong person, technically.

I didn't tell the client. I just fixed it and moved on. But it bothered me for days — not the mistake, the fact that I had no idea it was happening.

Why It Happens (and Why It's Not Obvious)

Git stores your identity in a config file at ~/.gitconfig. That's your global config. It applies everywhere on your machine unless something overrides it.

# this is probably set to whatever you used when you first installed Git
git config --global user.email
# → sandeep@personal.com

When you create or clone a repo, that global config is what Git uses — silently, automatically, every commit — until you tell it otherwise for that specific repo.

Most developers never do. Why would you? You set it up once years ago and forgot about it.

The problem only surfaces when you're juggling multiple contexts on one machine. Personal projects. Client work. A side job. A company laptop you also use for open source. Suddenly one identity doesn't cover it anymore.

The First Thing I Tried (Which Doesn't Really Solve It)

cd ~/clients/acme-dashboard
git config --local user.email "sandeep@work.com"

This works. It sets the email just for that repo by writing to .git/config inside it. Problem solved for this repo.

But I had eleven client repos. I went through all of them. Felt productive. Two days later I cloned a new one, started committing immediately, and forgot to run the command. Three commits in before I caught it.

--local is a fix for the symptom, not the cause. The cause is that you have to remember — and you won't, every time.

The Fix I Actually Use Now

Git has something called includeIf. It lets you load a different config file depending on which directory you're working in.

You set it up once. Then it just runs — automatically, in the background, every time you open a terminal in that folder. You never think about it again.

Here's how I set it up:

First, I organised my projects into folders by who I am when I work on them:

~/
├── clients/     ← freelance work
├── work/        ← day job
└── personal/    ← my own stuff

That folder structure is the trigger. Everything under ~/clients/ gets one identity. Everything under ~/personal/ gets another.

Then I created a config file for each identity:

# ~/.gitconfig-clients
[user]
    name  = Sandeep
    email = sandeep@work.com

# ~/.gitconfig-personal
[user]
    name  = Sandeep
    email = sandeep@personal.com

Then I added three lines to my global ~/.gitconfig:

[user]
    name  = Sandeep
    email = sandeep@personal.com   # the default fallback

[includeIf "gitdir:~/clients/"]
    path = ~/.gitconfig-clients

[includeIf "gitdir:~/work/"]
    path = ~/.gitconfig-work

That's the whole thing. When Git runs inside any repo under ~/clients/, it loads ~/.gitconfig-clients. The work email overrides the global personal one. When you're in ~/personal/, the global applies. Everything else gets the fallback.

Verify it:

cd ~/clients/acme-dashboard
git config user.email
# sandeep@work.com ✓

cd ~/personal/my-blog
git config user.email
# sandeep@personal.com ✓

No command after cloning. No checklist. No forgetting.

And when something looks wrong, this tells you exactly which file is responsible:

git config --show-origin user.email
# file:/Users/sandeep/.gitconfig-clients    sandeep@work.com

What About Two Different GitHub Accounts?

This is a separate problem that looks similar but isn't.

user.email controls what shows up in the commit author line. That's metadata. It has nothing to do with which GitHub account you're authenticated as when you push.

If you have a work GitHub account and a personal GitHub account, you need separate SSH keys. Otherwise you'll be authenticated as the same account no matter what email the commit shows.

# one key for each account
ssh-keygen -t ed25519 -f ~/.ssh/id_work     -C "work"
ssh-keygen -t ed25519 -f ~/.ssh/id_personal -C "personal"

Add each public key to the matching GitHub account. Then set up ~/.ssh/config so Git knows which key to use for which host:

Host github-work
    HostName     github.com
    User         git
    IdentityFile ~/.ssh/id_work

Host github-personal
    HostName     github.com
    User         git
    IdentityFile ~/.ssh/id_personal

Now clone using the alias instead of github.com:

git clone git@github-work:client-org/project.git
git clone git@github-personal:sandeep007/blog.git

Test that each one works:

ssh -T git@github-work
# Hi work-sandeep! You've successfully authenticated.

ssh -T git@github-personal
# Hi sandeep! You've successfully authenticated.

The Things That Will Trip You Up

The trailing slash matters. gitdir:~/clients and gitdir:~/clients/ are different. The version without the slash may not match subdirectories reliably. Always include it.

Check config from inside the repo. Running git config user.email outside a Git repo always returns the global value. If you're trying to verify it's working, cd into the actual project first.

The folder is the contract. Clone a client project into ~/personal/ by accident and it gets the personal identity. includeIf doesn't know what the project is — it only knows where .git lives. Respect the folder structure.

Windows needs full paths. The ~/ shorthand doesn't work reliably in gitdir: conditions on Windows. Use the full path instead: gitdir:C:/Users/Sandeep/clients/.

Honest Takeaway

I wasted two weeks of commit history and some amount of professional credibility because I didn't know this existed. The fix took me about ten minutes to set up once I found it.

includeIf is one of those Git features that feels almost too simple — you put it in one file and then you just never have to think about it again. The folder structure becomes the rule. Git enforces it silently.

If you work on more than one type of project on the same machine, set this up today. It costs you nothing and saves you from the specific embarrassment of a client asking who is writing all their code.

It takes 10 minutes — and can save your professional reputation.

If you found this useful, I write about TypeScript, Node.js, Security and DevOps
Follow Stack Dev Life for more real-world dev mistakes & fixes.
*Originally published at [stackdevlife.com]

Stop using `any` — here's how to type your messy API responses correctly

Sandeep Bansod — Mon, 06 Apr 2026 04:36:38 +0000

You cast the API response to any to stop TypeScript complaining. It worked. Now a field changed shape three months later and the bug is in production. Here's how to type messy API responses properly — with real validation, not just type assertions.

You've done it. Everyone has. The API returns something, TypeScript starts complaining, and the fastest fix is as any. The error goes away. You move on. Six weeks later, that field is null instead of a string, the bug is in production, and TypeScript said nothing — because you told it not to.

The problem is not that API responses are messy. They are, and always will be. The problem is that any doesn't model that mess — it erases it. You lose the one thing TypeScript is there to give you: a guarantee that your code matches your data.

This article covers the real techniques — from unknown to type guards to Zod to a fully typed fetch wrapper — that let you handle unpredictable API shapes without lying to the compiler.

The Real Problem with any

When you write const data = response.json() as any, TypeScript stops checking entirely. Every property access, every method call, every nested field — unchecked. You could write data.user.address.city.toUpperCase() and TypeScript would nod along even if address is undefined.

// This compiles. It will blow up at runtime.
const res  = await fetch('/api/user/1');
const data = (await res.json()) as any;

console.log(data.profile.avatar.url.trim());
//                       ^^^^^^ could be null
//                              ^^^ could be undefined
//                                  ^^^ TypeScript: fine by me

The worse version is as unknown as YourType — the double cast. It is exactly as dangerous as any, just more words. You're not adding safety, you're just suppressing a different error with extra ceremony.

// Still no actual validation — just a louder lie
const user = (await res.json()) as unknown as User;
console.log(user.email.toLowerCase()); // runtime error if email is null

The real issue is that fetch returns Promise<any>. The TypeScript standard library types Response.json() as returning any because it genuinely cannot know the shape. That's the compiler being honest. When you cast that any to your type, you're being dishonest on its behalf.

Your First Tool: unknown Instead of any

unknown is the honest version of any. It tells TypeScript: "I have a value and I don't know its shape yet." The critical difference is that TypeScript forces you to prove the shape before you use it. You cannot access properties on unknown without narrowing it first.

const res  = await fetch('/api/user/1');
const data: unknown = await res.json();

// TypeScript blocks this immediately
console.log(data.email);
// Error: Object is of type 'unknown'

// You must narrow it first
if (
  typeof data === 'object' &&
  data !== null &&
  'email' in data &&
  typeof (data as any).email === 'string'
) {
  console.log(data.email); // TypeScript: now it's safe
}

This is the right instinct but the wrong implementation for anything larger than a toy example. Writing inline narrowing for a 20-field API response is unreadable and unmaintainable. That's what type guards and schema validators are for.

Type Guards — Validate at the Boundary

A type guard is a function that takes an unknown value, validates its shape at runtime, and tells TypeScript what it is. The return type value is YourType is the key — it's called a type predicate, and it narrows the type inside any if block that uses it.

// types/user.ts
export interface User {
  id:        number;
  email:     string;
  name:      string;
  role:      'admin' | 'editor' | 'viewer';
  createdAt: string;
}

// guards/isUser.ts
export function isUser(value: unknown): value is User {
  return (
    typeof value === 'object' &&
    value !== null &&
    typeof (value as Record<string, unknown>).id        === 'number' &&
    typeof (value as Record<string, unknown>).email     === 'string' &&
    typeof (value as Record<string, unknown>).name      === 'string' &&
    ['admin', 'editor', 'viewer'].includes(
      (value as Record<string, unknown>).role as string
    )
  );
}

Now use it at the API boundary — the one place in your codebase where external data enters:

import { isUser } from '../guards/isUser';

export async function fetchUser(id: number): Promise<User> {
  const res  = await fetch(`/api/users/${id}`);
  const data: unknown = await res.json();

  if (!isUser(data)) {
    throw new Error(`Unexpected response shape from /api/users/${id}`);
  }

  // TypeScript knows `data` is User from here on
  return data;
}

Everything downstream of fetchUser works with a real User type — fully typed, autocompleted, checked on every property access. The mess is contained to the guard function.

The downside: writing guards by hand is verbose and easy to get wrong. If you add a field to the User interface, you have to remember to update the guard. If you don't, the guard silently misses the new field. For large or frequently changing APIs, use Zod.

Zod — Runtime Validation That Generates Types

Zod is a schema declaration library that solves the gap between your TypeScript type and your runtime validation. Instead of maintaining both a type and a guard separately, you define one schema and Zod generates the type from it automatically.

npm install zod

import { z } from 'zod';

// Define once — Zod generates the type AND validates at runtime
const UserSchema = z.object({
  id:        z.number(),
  email:     z.string().email(),
  name:      z.string().min(1),
  role:      z.enum(['admin', 'editor', 'viewer']),
  createdAt: z.string().datetime(),
});

// Type is inferred automatically — no separate interface needed
export type User = z.infer<typeof UserSchema>;

Now the fetch function becomes clean and fully safe:

export async function fetchUser(id: number): Promise<User> {
  const res  = await fetch(`/api/users/${id}`);
  const data: unknown = await res.json();

  // .parse() throws a ZodError with a detailed message if validation fails
  // .safeParse() returns { success, data, error } — use this in production
  const result = UserSchema.safeParse(data);

  if (!result.success) {
    console.error('Validation failed:', result.error.flatten());
    throw new Error(`Invalid response from /api/users/${id}`);
  }

  return result.data; // Fully typed User
}

result.error.flatten() gives you a structured breakdown of exactly which fields failed and why — far more useful than a generic "invalid response" message when you're debugging at 2AM.

The key difference from a type guard: if you add phoneNumber: z.string().optional() to UserSchema, the User type updates automatically. Schema and type are always in sync because they're the same thing.

Typing Partial and Nullable API Fields

Real APIs are messy. Fields are sometimes null, sometimes missing entirely, sometimes a string and sometimes a number depending on context. Zod handles all of these explicitly.

const OrderSchema = z.object({
  id:          z.number(),
  status:      z.enum(['pending', 'shipped', 'delivered', 'cancelled']),

  // nullable — the API returns null when not yet assigned
  assignedTo:  z.string().nullable(),

  // optional — the field may not be present at all
  couponCode:  z.string().optional(),

  // nullable AND optional — null or missing are both valid
  notes:       z.string().nullable().optional(),

  // coerce a string date to a Date object automatically
  shippedAt:   z.coerce.date().nullable(),

  // API returns strings for monetary values — validate and keep as string
  total:       z.string().regex(/^\d+\.\d{2}$/),

  // nested object
  address: z.object({
    line1:    z.string(),
    line2:    z.string().optional(),
    city:     z.string(),
    postcode: z.string(),
    country:  z.string().length(2), // ISO 3166-1 alpha-2
  }),

  // array of nested objects
  items: z.array(z.object({
    sku:      z.string(),
    quantity: z.number().int().positive(),
    price:    z.string(),
  })),
});

export type Order = z.infer<typeof OrderSchema>;

The generated Order type reflects all of this precisely — assignedTo: string | null, couponCode?: string, notes?: string | null | undefined. TypeScript will force you to handle the null and undefined cases. Not because you asked it to — because the schema told it to.

Handling API Errors Correctly

Most typed fetch examples only type the happy path. Real APIs return structured error objects too, and those have shapes worth validating.

// The error shape your API returns on 4xx / 5xx
const ApiErrorSchema = z.object({
  code:    z.string(),            // e.g. 'USER_NOT_FOUND'
  message: z.string(),
  details: z.record(z.string()).optional(), // field-level errors
});

export type ApiError = z.infer<typeof ApiErrorSchema>;

// A typed result type — no throwing unless truly unexpected
export type ApiResult<T> =
  | { ok: true;  data:  T        }
  | { ok: false; error: ApiError };

export async function fetchUser(id: number): Promise<ApiResult<User>> {
  const res  = await fetch(`/api/users/${id}`);
  const body: unknown = await res.json();

  if (!res.ok) {
    const errResult = ApiErrorSchema.safeParse(body);
    return {
      ok:    false,
      error: errResult.success
        ? errResult.data
        : { code: 'UNKNOWN', message: 'Unexpected error shape' },
    };
  }

  const result = UserSchema.safeParse(body);
  if (!result.success) {
    return { ok: false, error: { code: 'INVALID_SHAPE', message: 'Response schema mismatch' } };
  }

  return { ok: true, data: result.data };
}

Now at the call site, TypeScript forces you to handle both cases. No unchecked exceptions, no silent failures:

const result = await fetchUser(42);

if (!result.ok) {
  // result.error is typed as ApiError
  showToast(result.error.message);
  return;
}

// result.data is typed as User — fully safe from here
updateProfile(result.data);

Generic Fetch Wrapper with Full Type Safety

Once you have schemas, you can write one typed fetch utility and use it everywhere instead of duplicating the validation logic in every service function.

import { z, ZodSchema } from 'zod';

export type FetchResult<T> =
  | { ok: true;  data:  T      }
  | { ok: false; error: string; status: number };

export async function typedFetch<T>(
  url:     string,
  schema:  ZodSchema<T>,
  options?: RequestInit,
): Promise<FetchResult<T>> {
  let res: Response;

  try {
    res = await fetch(url, options);
  } catch (err) {
    return { ok: false, error: 'Network error', status: 0 };
  }

  const body: unknown = await res.json().catch(() => null);

  if (!res.ok) {
    const message = typeof body === 'object' && body !== null && 'message' in body
      ? String((body as Record<string, unknown>).message)
      : `HTTP ${res.status}`;
    return { ok: false, error: message, status: res.status };
  }

  const parsed = schema.safeParse(body);
  if (!parsed.success) {
    console.error('[typedFetch] schema mismatch:', parsed.error.flatten());
    return { ok: false, error: 'Invalid response shape', status: res.status };
  }

  return { ok: true, data: parsed.data };
}

Using it across your app:

// Any endpoint — just pass the schema
const userResult = await typedFetch(`/api/users/${id}`, UserSchema);
const orderResult = await typedFetch(`/api/orders/${id}`, OrderSchema);

// POST with body
const createResult = await typedFetch(
  '/api/users',
  UserSchema,
  {
    method:  'POST',
    headers: { 'Content-Type': 'application/json' },
    body:    JSON.stringify({ email: 'user@example.com', name: 'Riya' }),
  },
);

if (createResult.ok) {
  // createResult.data is User — fully typed
  console.log('Created:', createResult.data.email);
}

The schema is the only thing that changes between endpoints. All error handling, network error recovery, and logging lives in one place.

When the API Shape Changes Without Warning

Third-party APIs change. Internal APIs change. The backend team renames a field and forgets to tell you. With any, this breaks silently at runtime. With Zod, the safeParse fails immediately with a clear error message pointing to the exact field.

Two Zod tools are useful here:

z.object().passthrough() — validates the fields you defined but allows extra unknown fields through. Useful when the API adds fields you don't need yet, without breaking validation:

// Extra fields from the API are allowed through — your type stays clean
const UserSchema = z.object({
  id:    z.number(),
  email: z.string(),
  name:  z.string(),
}).passthrough();

z.object().strip() (the default) — strips unknown fields. Safer for security-sensitive contexts where you don't want unexpected data flowing through your app.

For APIs that evolve, use .catch() to provide fallback values for non-critical fields instead of failing the whole parse:

const UserSchema = z.object({
  id:     z.number(),
  email:  z.string(),
  name:   z.string(),

  // If the API stops sending `avatarUrl`, fall back to null
  // instead of throwing a validation error
  avatarUrl: z.string().nullable().catch(null),

  // If `theme` is an unexpected value, default to 'light'
  theme: z.enum(['light', 'dark']).catch('light'),
});

This gives you a resilient schema — strict on the fields that matter, graceful on the fields that might drift.

Common Mistakes

Using as YourType instead of actually validating — a type assertion tells TypeScript what you believe the shape is, not what it actually is. If you're wrong, TypeScript cannot help you
Validating in components instead of at the fetch boundary — validation belongs in your service or API layer, not scattered across UI components. Components should receive already-validated, fully-typed data
Marking everything optional to avoid validation failures — z.string().optional() on a required field means you'll get undefined where you don't expect it. Be strict on required fields; only use optional where the API contract genuinely allows absence
Using .parse() instead of .safeParse() in production code — .parse() throws a ZodError on failure, which means unhandled promise rejections unless you wrap every call in try/catch. Use .safeParse() and handle the error branch explicitly
Writing a separate interface and a separate guard — this is the pre-Zod pattern that created the sync problem in the first place. With Zod, z.infer is your type. One source of truth

The Takeaway

any doesn't solve the problem of messy API responses — it hides it until runtime. unknown forces you to be explicit. Type guards add reusable validation. Zod makes schema and type the same thing so they can never go out of sync. A generic typedFetch wrapper brings it all together so validation happens once, consistently, at the boundary where external data enters your app. After that, the rest of your codebase works with real types — and TypeScript can actually protect you.

If you found this useful, I write about TypeScript, Node.js, Security and DevOps at stackdevlife.com — drop a follow if you'd like more!

Originally published at stackdevlife.com

Environment Variables You're Leaking to the Frontend Without Knowing It

Sandeep Bansod — Sun, 05 Apr 2026 09:09:00 +0000

You added NEXT_PUBLIC_ to your API key "just to test something quickly". That was six months ago. It's still there.

Most developers know the rule: secret keys go in .env, never in client code. But the actual leaks aren't that obvious. They don't happen because someone is careless — they happen because the tooling is confusing, the error messages are silent, and the mistakes look completely fine until someone opens DevTools or pulls your bundle.

Mistake 1 — The NEXT_PUBLIC_ prefix on secrets

Next.js exposes any variable prefixed with NEXT_PUBLIC_ to the browser. That's by design. The problem is developers reach for it the moment they hit a "variable is undefined" error on the client side — without asking why it's undefined.

# .env.local

# Fine — this is meant to be public
NEXT_PUBLIC_API_URL=https://api.example.com

# DANGER — now exposed in every JS bundle
NEXT_PUBLIC_STRIPE_SECRET_KEY=sk_live_xxxxxxxxx
NEXT_PUBLIC_DATABASE_URL=postgres://user:password@host/db

Anyone can open your deployed site, go to Network → JS files, search for sk_live_ and find it.

Stripe secret keys have a very recognizable prefix. So do AWS access keys (AKIA), Supabase service role keys, and SendGrid API keys.

The fix: if your key is only used in API routes or server components, it should never have NEXT_PUBLIC_. Call a backend route instead.

// Wrong — secret key exposed to client
const stripe = new Stripe(process.env.NEXT_PUBLIC_STRIPE_SECRET_KEY!);

// Right — only used in /api/checkout/route.ts (server-side)
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

Mistake 2 — Vite's import.meta.env and the VITE_ prefix

Vite works exactly the same way. Any variable prefixed with VITE_ gets statically inlined into your bundle at build time. It's not fetched at runtime — it's literally copied into your JavaScript.

VITE_API_URL=https://api.example.com        # fine
VITE_SUPABASE_ANON_KEY=eyJhbGciOiJIUzI1Ni   # fine
VITE_SUPABASE_SERVICE_KEY=eyJhbGciOiJIUzI1Ni...  # never prefix this

Run npm run build then open dist/assets/index-xxxx.js and search for your key. You'll find it in plain text, wrapped in production whatever.

Mistake 3 — process.env in bundled client code

With Create React App or older webpack setups, REACT_APP_ variables get inlined. But even without that pattern, developers sometimes write shared utility files that get pulled into the client bundle without realizing it.

// utils/config.ts — imported by both client and server code
export const config = {
  apiUrl: process.env.API_URL,
  stripeKey: process.env.STRIPE_SECRET_KEY,
};

The safe pattern: never import server config into code that's shared with the client.

// lib/server-config.ts — only imported in server files
export const serverConfig = {
  apiUrl: process.env.API_URL,
  stripeKey: process.env.STRIPE_SECRET_KEY,
};

// lib/client-config.ts — safe to import anywhere
export const clientConfig = {
  apiUrl: process.env.NEXT_PUBLIC_API_URL,
};

Mistake 4 — Exposing .env through source maps

You've been careful with your variables. But did you ship source maps to production? Source maps reconstruct your original source code in the browser. If your server-side code ends up in a source map in your production build, the DevTools Sources tab will show the original file — including any hardcoded fallbacks.

// A common but dangerous pattern
const key = process.env.STRIPE_SECRET_KEY || "sk_live_fallback_for_dev";

In Next.js, make sure source maps stay off in production:

// next.config.js
module.exports = {
  productionBrowserSourceMaps: false, // default is false — make sure it stays that way
};

For Vite:

// vite.config.ts
export default defineConfig({
  build: {
    sourcemap: false, // or "hidden" if you need them for error tracking only
  },
});

Mistake 5 — The API debug route you forgot to remove

This one is embarrassing but common. During local debugging, you add a quick route to dump env state. You commit it. It goes to production.

https://yourapp.com/api/debug

Now returns every single environment variable on your server.

// pages/api/debug.ts
export default function handler(req, res) {
  res.json({ env: process.env }); // must never go to production
}

How to audit what you're actually shipping

Build your app and grep the bundle for known secret patterns:

# Next.js
npm run build
grep -r "sk_live\|AKIA\|password\|secret" .next/static/chunks/

# Vite
npm run build
grep -r "sk_live\|AKIA\|password\|secret" dist/assets/

Common mistakes

Prefixing secrets "temporarily" to fix a client-side undefined error — the root cause is architectural, not a missing prefix
Sharing a single config file between server and client code — split them and enforce it with ESLint import rules
Using fallbacks with real keys — process.env.KEY || "real-key-here" defeats the entire point
Forgetting that third-party SDKs initialized client-side log their config (Sentry, Supabase, Firebase initialized with wrong keys expose them in network requests)

The takeaway

The leaks that hurt you aren't the obvious ones — they're the subtle ones. Every time you see NEXT_PUBLIC_, you added in a rush, the shared config file that got bundled, the debug route that made it to production. Build a habit: before any deploy, grep your bundle for known secret patterns, keep a hard separation between server and client config, and treat every environment variable as guilty until proven safe to expose.

If you found this useful, I write about TypeScript, Node.js, Security and DevOps at stackdevlife.com — drop a follow if you'd like more!

Originally published at stackdevlife.com

DEV Community: Sandeep Bansod

We Deployed a "Small Fix" and Took Down Production — Here's What Actually Happened

The Incident

What Changed?

The Real Problem

Why It Broke Production

Why We Didn't Catch It

The Fix

Result After Fix

Lessons Learned

1. Never trust .populate() blindly

2. Always think in queries

3. Test with realistic data

4. Add performance monitoring

5. Use .lean() when possible

Bonus: Safer Alternative Pattern

Final Thought

We Ran git rebase on a Shared Branch and Lost Three Days of Work

What git rebase Actually Does to History

How the Disaster Unfolded

The Error That Should Have Stopped It

How We Recovered

Step 1: Stop everyone from pulling or pushing immediately

Step 2: Find the lost commits with git reflog

Step 3: Restore the remote branch from the recovery point

Step 4: Help teammates rebase their local branches onto the restored remote

The Actual Fix: Never Let This Happen Again

The Takeaway

Originally published at stackdevlife.com

ESM vs CJS — Why Your import Still Breaks in 2026 and How to Finally Fix It

The Root Problem: Two Module Systems That Don't Like Each Other

How Node Decides Which System to Use

The Five Errors You'll Actually Hit

Error 1: ERR_REQUIRE_ESM

Error 2: ERR_MODULE_NOT_FOUND with ESM

Error 3: __dirname and __filename are not defined

Error 4: Named exports break from CJS packages

Error 5: Dual package hazard — the silent one

The Real Fix: Converting a Node.js Project to Pure ESM

When You Can't Migrate: The Dynamic Import Workaround

GitHub Repository

The Takeaway

How I Fixed a Node.js API That Was Taking 15 Minutes to Return 8,000 Records

The Setup

Step 1: Find Out What MongoDB Is Actually Doing

Step 2: Add the Right Indexes

Step 3: Fix the Aggregation Pipeline

Step 4: Refactor the API Code

The Results

What to Actually Check When You Inherit a Slow API

I Used the Wrong Git Email for 2 Weeks — And No One Noticed

Why It Happens (and Why It's Not Obvious)

The First Thing I Tried (Which Doesn't Really Solve It)

The Fix I Actually Use Now

What About Two Different GitHub Accounts?

The Things That Will Trip You Up

Honest Takeaway

Stop using `any` — here's how to type your messy API responses correctly

The Real Problem with any

Your First Tool: unknown Instead of any

Type Guards — Validate at the Boundary

Zod — Runtime Validation That Generates Types

Typing Partial and Nullable API Fields

Handling API Errors Correctly

Generic Fetch Wrapper with Full Type Safety

When the API Shape Changes Without Warning

Common Mistakes

The Takeaway

Environment Variables You're Leaking to the Frontend Without Knowing It

Mistake 1 — The NEXT_PUBLIC_ prefix on secrets

Mistake 2 — Vite's import.meta.env and the VITE_ prefix

Mistake 3 — process.env in bundled client code

Mistake 4 — Exposing .env through source maps

Mistake 5 — The API debug route you forgot to remove

How to audit what you're actually shipping

Common mistakes

The takeaway

1. Never trust `.populate()` blindly

5. Use `.lean()` when possible

Error 3: dirname and filename are not defined