DEV Community: shruti jain

Error Handling in Express.js

shruti jain — Sat, 26 Jul 2025 07:45:20 +0000

When building backend applications with Express.js, handling errors properly is crucial. It not only helps you debug issues quickly but also ensures a better experience for users when something goes wrong.

In this blog, we'll walk through how error handling works in Express, why it matters, and how you can implement it in your own projects.

What is Error Handling?

Error handling is the process of catching and responding to errors in your application. These errors could be anything from a missing file, a bad request, a database failure, or even a typo in your code. Instead of letting the app crash or return confusing messages, we use error handlers to catch these issues and return useful responses.

How Express Handles Errors

Express has a special kind of middleware just for errors. This middleware function must have four arguments: err, req, res, and next. Express automatically knows it's an error handler because of the first err parameter.

Here’s a basic error handler:

app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(500).json({ message: 'Something went wrong!' });
});

You should add this at the end of all your route definitions so it can catch any errors from above.

Throwing and Catching Errors

1. Throwing Errors in Routes

You can directly throw an error in a route:

app.get('/', (req, res) => {
  throw new Error('Server crashed');
});

Express will send this error to the error-handling middleware automatically.

2. Using `next()` to Pass Errors

Instead of throwing, you can also pass the error using next():

app.get('/manual', (req, res, next) => {
  const err = new Error('Something went wrong manually');
  err.status = 400;
  next(err);
});

Then in your error handler, you can use err.status to return the correct status code.

Handling Errors in Async Code

Express doesn't automatically catch errors in async functions. You need to use a try/catch block or write a helper to manage this.

Option 1: try/catch

app.get('/async', async (req, res, next) => {
  try {
    const data = await someAsyncFunction();
    res.send(data);
  } catch (err) {
    next(err);
  }
});

Option 2: Wrapper Function

You can avoid repeating try/catch by using a helper:

const asyncHandler = fn => (req, res, next) => {
  Promise.resolve(fn(req, res, next)).catch(next);
};

app.get('/safe', asyncHandler(async (req, res) => {
  const data = await someAsyncFunction();
  res.send(data);
}));

Handling 404 (Route Not Found)

If a user tries to access a route that doesn’t exist, you can handle it like this:

app.use((req, res) => {
  res.status(404).json({ message: 'Route not found' });
});

This should be added just before the final error handler.

Full Example Structure

Here’s how your basic Express app might look with proper error handling:

const express = require('express');
const app = express();

// Routes
app.get('/', (req, res) => {
  throw new Error('Home error');
});

// 404 Handler
app.use((req, res) => {
  res.status(404).json({ message: 'Not Found' });
});

// Error Handler
app.use((err, req, res, next) => {
  const status = err.statusCode || 500;
  res.status(status).json({ message: err.message || 'Internal Server Error' });
});

app.listen(3000, () => console.log('Server is running on port 3000'));

Conclusion

Good error handling in Express.js makes your application more reliable and easier to maintain. By using middleware properly and planning for both sync and async errors, you can build a backend that handles problems gracefully without confusing your users or crashing your server.

If you're just starting out with Express, try adding error handlers to your projects today and see how it improves your debugging and stability.

Git Branch Management: Merged, Unmerged, and Clean-Up — A No-Nonsense Cheatsheet

shruti jain — Mon, 21 Jul 2025 16:01:17 +0000

Keeping your Git repo clean is underrated. I’ve seen teams drown in a sea of stale branches — some merged, some half-baked, some lost to time.

So here’s a practical cheatsheet I put together to manage local branches like a pro. If you’re tired of guessing what's merged and what's just wasting disk space, this one’s for you.

🔍 1. List Local Branches Merged into `master`

git branch --merged master

Why: These are safe to delete. Their commits are already in master.

🔍 2. List Local Branches Not Merged into `master`

git branch --no-merged master

Why: These might have unmerged work. Review before deleting.

✅ 3. Check if a Specific Branch Is Fully Merged

git merge-base --is-ancestor your-branch master && echo "Merged ✅" || echo "Not merged ❌"

Why: Quick yes/no check without manually scanning logs.

🍒 4. See What’s Unique to Your Branch (`git cherry` FTW)

git cherry master your-branch

+ = unique commit in your branch
- = already in master
No output = fully merged

🧼 5. Delete Local Branches

git branch -d your-branch    # Safe delete (if merged)
git branch -D your-branch    # Force delete (if unmerged)

Use with caution. Especially -D.

☁️ 6. Delete Remote Branch

git push origin --delete your-branch

Why: Local cleanup is one thing. Don't leave junk on origin either.

⏱ 7. Sort Local Branches by Last Commit Date

git for-each-ref --sort=-committerdate --format="%(committerdate:short)  %(refname:short)" refs/heads/

Why: Spot stale or abandoned branches quickly.

📊 8. One-Liner: Show Merged vs Not Merged Branches

echo "=== Merged ==="; git branch --merged master; echo ""; echo "=== Not Merged ==="; git branch --no-merged master

Why: Good for audits and cleanup days.

🧽 9. Auto-Delete All Safe-to-Remove Local Branches

git branch --merged master | grep -vE '^\*|master|main|dev' | xargs -n 1 git branch -d

Why: Deletes all merged local branches except the important ones (master, main, dev, current branch).

🎯 Bonus Tip: Automate It

Add a script or alias for regular cleanup. Git hygiene = happier devs + cleaner merges.

Final Thoughts

Don’t let your repo turn into a graveyard of zombie branches. A few CLI tricks like these can keep things lean, understandable, and merge-conflict-free.

Got a favorite cleanup command or Git trick? Drop it in the comments — let’s trade war tools.

Supercharge Your Website: A Deep Dive into HTTP Caching

shruti jain — Wed, 26 Mar 2025 06:45:28 +0000

In today's fast-paced digital landscape, website speed is more critical than ever. Users expect web pages to load instantly; even a slight delay can result in lost traffic and frustrated visitors. One of the most effective ways to enhance website performance is through HTTP caching. In this guide, we’ll explore what HTTP caching is, why it matters, and how you can implement it to optimize your website.

What is HTTP Caching?

HTTP caching is the process of storing copies of web resources (such as HTML pages, images, CSS files, and JavaScript files) in temporary storage locations known as caches. When a user requests a resource, the browser or an intermediate cache checks whether it already has a fresh copy, if it does, the cached version is served instead of fetching the resource from the origin server. This significantly reduces load time and improves the overall user experience.

Why is Caching Important?

Caching offers several benefits that can transform website performance:

Reduced Latency: Loading resources from a cache is much faster than fetching them from a remote server.
Bandwidth Savings: Less data is transferred over the network, benefiting both servers and users, especially those on mobile networks.
Scalability: Reducing server load allows websites to handle more traffic efficiently.
Improved SEO: Search engines prioritize fast-loading websites, giving cached sites a ranking advantage.
Better User Experience: Faster load times lead to higher user satisfaction and engagement.

Types of Caches

There are several caching mechanisms at play in HTTP caching:

Browser Cache: Stores web resources locally on a user's device, allowing quick access to repeated content.
Proxy Cache: Used in corporate networks or ISPs to store frequently accessed resources, reducing bandwidth consumption.
CDN (Content Delivery Network) Cache: CDNs store copies of resources in multiple locations worldwide, serving content from the closest server to the user.

Understanding HTTP Cache Headers

HTTP caching relies on specific headers that control how resources are cached. These headers guide browsers, proxies, and CDNs on how to handle cached content.

Key Cache-Control Directives

public: Allows caching by any cache (browser, proxy, CDN).
private: Restricts caching to the user’s browser only, preventing storage in shared caches.
max-age=seconds: Defines how long a resource remains fresh before requiring validation.
s-maxage=seconds: Similar to max-age, but applies only to shared caches (CDNs, proxies).
stale-while-revalidate=seconds: Allows serving stale content while fetching an updated version.
stale-if-error=seconds: Allows serving stale content if the origin server is unreachable.
no-cache: Forces the cache to validate the resource with the origin server before using it.
no-store: Prevents caching altogether, used for sensitive data.

Other Important Headers

ETag: Assigns a unique identifier to a resource version, aiding efficient revalidation.
Last-Modified: Indicates the last time a resource was changed, helping determine if an update is needed.

Practical Examples of Cache-Control in Action

1. Static Assets (Images, CSS, JavaScript)

These resources rarely change and should be cached for a long time.

Cache-Control: public, max-age=31536000, s-maxage=31536000, stale-while-revalidate=60, stale-if-error=86400

Fresh for 1 year in both browsers and CDNs.
Can serve stale content for 60 seconds while revalidating.
If revalidation fails, stale content can be served for 24 hours.

2. API Responses (Frequently Changing Data)

APIs often return data that changes frequently but still benefits from short-term caching.

Cache-Control: public, max-age=3600, s-maxage=86400, stale-while-revalidate=60, stale-if-error=86400

Fresh for 1 hour in browsers, 24 hours in CDNs.
Stale content can be served for 60 seconds while revalidating.
If an error occurs, stale content can be used for 24 hours.

3. User-Specific Data (Personalized Content)

Data tied to individual users should not be cached by shared caches.

Cache-Control: private, max-age=600

Fresh for 10 minutes, but only cached in the user's browser.

4. Sensitive Data (No Caching Allowed)

For sensitive information, caching must be completely disabled.

Cache-Control: no-store

Ensures data is never stored in any cache.

Caching Strategies for Maximum Performance

To make the most of HTTP caching, consider implementing these strategies:

CDN Caching: Use a CDN to cache static assets and frequently accessed API responses.
Browser Caching: Set Cache-Control headers with public or private to manage browser cache behavior.
Revalidation: Use ETag and Last-Modified to enable efficient resource validation.
Stale Content Handling: Utilize stale-while-revalidate and stale-if-error to improve user experience during revalidation or errors.

Conclusion

HTTP caching is an essential technique for optimizing website performance, reducing server load, and enhancing the user experience. By leveraging the right cache headers and strategies, you can significantly improve your website’s speed and efficiency.

Call to Action

Start optimizing your website today with HTTP caching. Experiment with different Cache-Control directives and monitor the impact on performance.

Key Takeaways for Developers

Caching is critical for performance optimization.
Cache-Control is the primary tool for managing cache behavior.
public vs. private determines who can cache a resource.
max-age and s-maxage control how long resources stay fresh.
stale-while-revalidate and stale-if-error improve user experience.
CDNs boost performance for global audiences.
ETag and Last-Modified enable efficient resource validation.

Implementing caching correctly can make a huge difference in site speed, scalability, and user satisfaction. Take advantage of HTTP caching today and watch your website perform at its best.

Optimizing MongoDB Queries with `.executionStats`

shruti jain — Thu, 27 Feb 2025 16:08:37 +0000

As developers, we often focus on writing functional queries, but ensuring they run efficiently is just as important. MongoDB provides a powerful tool—.executionStats—that helps analyze query performance and optimize database operations. Let’s explore how it works and why it’s useful in day-to-day development.

What is `.executionStats`?

In MongoDB, .executionStats is a mode in the explain() method that provides in-depth insights into how a query executes. It helps you understand query performance, index usage, and potential optimizations.

How to Use `.executionStats`

To analyze a query’s performance, run:

 db.collection.find(query).explain("executionStats")

For example, if you want to check the performance of a query fetching users older than 25:

 db.users.find({ age: { $gt: 25 } }).explain("executionStats")

This will return a detailed JSON output containing various execution metrics.

Key Metrics in `.executionStats`

Here are some critical fields to look at:

executionSuccess – Indicates whether the query executed successfully.
nReturned – Number of documents returned by the query.
executionTimeMillis – Total execution time (in milliseconds).
totalKeysExamined – Number of index keys examined.
totalDocsExamined – Number of documents scanned in the collection.
executionStages – Details about how MongoDB executed the query.

Why is This Useful for Developers?

🔍 Identifying Slow Queries

If executionTimeMillis is high, the query might be inefficient. Identifying slow queries helps in improving performance, especially for large datasets.

📊 Index Optimization

If totalDocsExamined is much higher than nReturned, MongoDB is scanning too many documents.
If totalKeysExamined is high, an index might not be working effectively.
This helps in deciding whether to create, modify, or remove indexes.

🛠 Debugging Execution Plans

If a query isn’t using an index as expected, .executionStats can help diagnose why. This prevents full collection scans and speeds up response times.

🚀 Improving Scalability

Optimizing queries ensures they can handle large traffic loads without causing high CPU or memory usage, making your application more scalable.

🔄 Comparing Query Performance

By testing different queries and comparing their .executionStats, developers can determine the most efficient approach for retrieving data.

Example: Optimizing a Query

Let’s say you run the following query:

 db.orders.find({ status: "shipped" }).explain("executionStats")

If the output shows:

{
  "nReturned": 10,
  "totalDocsExamined": 10000,
  "executionTimeMillis": 120
}

This means MongoDB is scanning 10,000 documents to return just 10! The solution? Add an index:

 db.orders.createIndex({ status: 1 })

After indexing, running .executionStats again might show:

{
  "nReturned": 10,
  "totalDocsExamined": 10,
  "executionTimeMillis": 5
}

This massive improvement makes the database more responsive and efficient.

Conclusion

Using .executionStats regularly helps developers:
✅ Identify slow queries

✅ Optimize indexes

✅ Debug query execution plans

✅ Improve database scalability

✅ Ensure applications run smoothly even under high loads

Next time you write a MongoDB query, don’t just check if it works—check how well it works! 🚀

Do you have a query that needs optimization? Share it in the comments! 😃

Removing a Tracked File from Git After Adding It to .gitignore

shruti jain — Wed, 19 Feb 2025 10:03:05 +0000

Sometimes, we accidentally commit files that should have been ignored, like config/config.js, .env, or node_modules/. Adding them to .gitignore after committing doesn’t remove them from Git's history. Here’s how you fix it properly.

Step 1: Add the File to `.gitignore`

First, make sure the file is listed in .gitignore.

# Ignore config file
config/config.js

Step 2: Remove the File from Git Tracking

Since Git is already tracking the file, we need to untrack it without deleting it from the local system.

Run this command:

git rm --cached config/config.js

✅ This removes it from Git without deleting it locally.

Step 3: Commit and Push the Change

Now, commit this change:

git commit -m "Removed config.js from repo"
git push origin main  # Change 'main' if using a different branch

From now on, Git will ignore config/config.js, and it won’t be included in future commits.

Bonus: Remove It from Git History (If Already Pushed)

If the file was already pushed and contains sensitive data, you need to rewrite Git history:

git filter-branch --force --index-filter \
'git rm --cached --ignore-unmatch config/config.js' \
--prune-empty --tag-name-filter cat -- --all

Then force push the changes:

git push origin --force --all

⚠ Warning: This rewrites history, so be cautious if working in a shared repository!

Now your secret files are safe, and Git will ignore them in the future! 🚀

Stop Wasting Memory: Use .lean() Like a Pro

shruti jain — Mon, 17 Feb 2025 06:59:59 +0000

Introduction

Alright, let’s talk about something that should be common sense but somehow isn’t: using .lean() in Mongoose. If you’ve ever written a simple query and thought, “Why is my app using so much memory?”, chances are you’re not using .lean(). And if you're the kind of developer who likes to flex about performance optimizations but still ignores .lean(), this one's for you.

What the Heck is `.lean()`?

Mongoose normally returns full-fat documents, loaded with built-in magic: getters, setters, hooks, change tracking—you name it. But let’s be real: 90% of the time, you don’t need that extra fluff when you're just reading data.

Enter .lean(), a simple method that tells Mongoose:

“Hey, don’t give me a fancy, bloated document. Just give me a plain JavaScript object.”

And boom! You just saved memory, improved query speed, and maybe even made your API 10% less of a dumpster fire.

How `.lean()` Works (With Examples)

Without `.lean()` (The Memory Hog Approach)

const article = await ArticlesModel.findOne({ title: "How to Waste Memory" });
console.log(article);
// Output: Mongoose Document with tons of hidden properties

console.log(typeof article); // "object" (but a heavy Mongoose object)
console.log(article.save); // Function exists! (But you never needed it, did you?)

Here’s the problem: this returns a full Mongoose document, packed with hidden features like .save(), .validate(), and other things you will never use in a read operation.

With `.lean()` (The Smart Way)

const article = await ArticlesModel.findOne({ title: "How to Optimize Performance" }).lean();
console.log(article);
// Output: { _id: "abc123", title: "How to Optimize Performance" }

console.log(typeof article); // "object" (plain JavaScript object)
console.log(article.save); // undefined (because you never needed it!)

✅ Boom! Faster, lighter, and without unnecessary Mongoose baggage.

Why Should You Care?

1. .lean() Makes Queries Faster ⚡

Full Mongoose documents come with extra processing.
.lean() skips that overhead and returns raw JSON objects.

2. .lean() Saves Memory 🧠

Mongoose docs retain a reference to the database (more memory).
Plain objects? Lighter, easier to work with, and don’t bloat your app.

3. Avoids Unnecessary Features 🚀

Do you need .save() on a read query? No.
Do you need schema validation on an already stored document? Nope.
Do you need virtuals? Then don’t use .lean() (more on this below).

When NOT to Use `.lean()`

I get it—.lean() sounds like magic. But don’t get too excited; it’s not always the right choice. Here’s when you shouldn’t use it:

🚨 If You Need Schema Features (Virtuals, Hooks, Middleware)

const userSchema = new mongoose.Schema({
  firstName: String,
  lastName: String,
}, {
  toJSON: { virtuals: true },
});

userSchema.virtual("fullName").get(function () {
  return `${this.firstName} ${this.lastName}`;
});

const user = await UserModel.findOne({ firstName: "John" }).lean();
console.log(user.fullName); // undefined (because `.lean()` removes virtuals!)

💡 Solution? Don’t use .lean() if you need schema-based transformations.

🚨 If You Need to Modify and Save the Document

const user = await UserModel.findOne({ name: "Alice" }).lean();
user.age = 30;
await user.save(); // ❌ ERROR! save() doesn't exist on plain objects.

💡 Solution? If you plan to update and save the document, skip .lean().

The TL;DR for Lazy Developers

✅ Use .lean() when:

You only need to read data.
You want faster, lightweight queries.
You don’t need .save(), hooks, or virtuals.

⛔ Don’t use .lean() when:

You need virtuals, middleware, or hooks.
You’re going to modify and save the document.

Final Thoughts

Mongoose is great, but blindly using full documents everywhere is just bad practice. If your app is sluggish or consuming too much memory, .lean() is a simple, one-line fix that can make a big difference.

So next time someone asks “Why is our API so slow?”, just reply:

“Did you use .lean()?”

And if they say no, well… you know who to blame. 😎

Self-Updating Widgets (No Manual Changes!)

shruti jain — Fri, 07 Feb 2025 10:56:52 +0000

💡 Problem: What if you release an update, but users have already embedded an old version?

✅ Solution: Use a versioning system in your script URL:

<script src="https://cdn.yourdomain.com/widget.js?v=2.0.1"></script>

Or, force fresh loads by appending a timestamp:

<script src="https://cdn.yourdomain.com/widget.js?t=" + Date.now()></script>

This ensures no cache issues and always loads the latest version.

Serving a Widget Using Node.js 🚀

shruti jain — Fri, 07 Feb 2025 10:46:28 +0000

Widgets—those little UI elements like chat popups and notifications—are super handy. Here’s a quick way to build and serve a widget using Node.js, making it embeddable with a simple <script> tag.

1️⃣ Set Up the Server

mkdir widget-server && cd widget-server  
npm init -y  
npm install express

Create server.js:

const express = require('express');
const path = require('path');
const app = express();
const PORT = 3000;

app.get('/widget', (req, res) => res.sendFile(path.join(__dirname, 'widget.html')));

app.get('/embed.js', (req, res) => {
    res.setHeader('Content-Type', 'application/javascript');
    res.send(`
        (function() {
            let iframe = document.createElement('iframe');
            iframe.src = 'http://localhost:${PORT}/widget';
            iframe.style = 'width:320px;height:200px;border:none;position:fixed;bottom:20px;right:20px;z-index:9999;';
            document.body.appendChild(iframe);
        })();
    `);
});

app.listen(PORT, () => console.log(`Server running at http://localhost:${PORT}`));

2️⃣ Create the Widget

Create widget.html:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Widget</title>
    <style>
        body { font-family: Arial, sans-serif; text-align: center; padding: 10px; }
        button { background: #007BFF; color: #fff; padding: 10px; border: none; cursor: pointer; }
    </style>
</head>
<body>
    <h3>My Widget</h3>
    <button>Click Me</button>
</body>
</html>

3️⃣ Embed It Anywhere

<script src="http://localhost:3000/embed.js"></script>

Run the server:

node server.js

This will load the widget inside an iframe on any webpage. 🚀****

DEV Community: shruti jain

Error Handling in Express.js

What is Error Handling?

How Express Handles Errors

Throwing and Catching Errors

1. Throwing Errors in Routes

2. Using next() to Pass Errors

Handling Errors in Async Code

Option 1: try/catch

Option 2: Wrapper Function

Handling 404 (Route Not Found)

Full Example Structure

Conclusion

Git Branch Management: Merged, Unmerged, and Clean-Up — A No-Nonsense Cheatsheet

🔍 1. List Local Branches Merged into master

🔍 2. List Local Branches Not Merged into master

✅ 3. Check if a Specific Branch Is Fully Merged

🍒 4. See What’s Unique to Your Branch (git cherry FTW)

🧼 5. Delete Local Branches

☁️ 6. Delete Remote Branch

⏱ 7. Sort Local Branches by Last Commit Date

📊 8. One-Liner: Show Merged vs Not Merged Branches

🧽 9. Auto-Delete All Safe-to-Remove Local Branches

🎯 Bonus Tip: Automate It

Final Thoughts

Supercharge Your Website: A Deep Dive into HTTP Caching

What is HTTP Caching?

Why is Caching Important?

Types of Caches

Understanding HTTP Cache Headers

Key Cache-Control Directives

Other Important Headers

Practical Examples of Cache-Control in Action

1. Static Assets (Images, CSS, JavaScript)

2. API Responses (Frequently Changing Data)

3. User-Specific Data (Personalized Content)

4. Sensitive Data (No Caching Allowed)

Caching Strategies for Maximum Performance

Conclusion

Call to Action

Key Takeaways for Developers

Optimizing MongoDB Queries with `.executionStats`

What is .executionStats?

How to Use .executionStats

Key Metrics in .executionStats

Why is This Useful for Developers?

🔍 Identifying Slow Queries

📊 Index Optimization

🛠 Debugging Execution Plans

🚀 Improving Scalability

🔄 Comparing Query Performance

Example: Optimizing a Query

Conclusion

Removing a Tracked File from Git After Adding It to .gitignore

Step 1: Add the File to .gitignore

Step 2: Remove the File from Git Tracking

Step 3: Commit and Push the Change

Bonus: Remove It from Git History (If Already Pushed)

Stop Wasting Memory: Use .lean() Like a Pro

Introduction

What the Heck is .lean()?

How .lean() Works (With Examples)

Without .lean() (The Memory Hog Approach)

With .lean() (The Smart Way)

Why Should You Care?

When NOT to Use .lean()

The TL;DR for Lazy Developers

Final Thoughts

Self-Updating Widgets (No Manual Changes!)

Serving a Widget Using Node.js 🚀

1️⃣ Set Up the Server

2️⃣ Create the Widget

3️⃣ Embed It Anywhere

2. Using `next()` to Pass Errors

🔍 1. List Local Branches Merged into `master`

🔍 2. List Local Branches Not Merged into `master`

🍒 4. See What’s Unique to Your Branch (`git cherry` FTW)

What is `.executionStats`?

How to Use `.executionStats`

Key Metrics in `.executionStats`

Step 1: Add the File to `.gitignore`

What the Heck is `.lean()`?

How `.lean()` Works (With Examples)

Without `.lean()` (The Memory Hog Approach)

With `.lean()` (The Smart Way)

When NOT to Use `.lean()`