Forem: Bhupesh Chandra Joshi

URL Parameters vs Query Strings in Express.js: A Practical Guide

Bhupesh Chandra Joshi — Fri, 08 May 2026 17:18:48 +0000

Master route params and query strings for cleaner, more RESTful Node.js APIs

Introduction

When building APIs with Express.js, handling dynamic data from URLs is fundamental. Two common mechanisms—URL Parameters (route params) and Query Strings (query params)—often confuse beginners. Understanding when and how to use each leads to more intuitive, performant, and maintainable APIs.

In this practical guide, you'll learn the differences, how to access them in Express, real-world examples, and best practices. Let's dive in.

1. What are URL Parameters (Route Params)?

URL Parameters are dynamic segments of the URL path itself. They act as identifiers for a specific resource.

Defined in your route using a colon (:) prefix.
Part of the URL structure, not optional by default.
Ideal for targeting a unique resource.

Example URL:

https://api.example.com/users/123

Here, 123 is the user ID.

In Express route:

app.get('/users/:id', (req, res) => {
  // ...
});

2. What are Query Strings (Query Parameters)?

Query Strings are key-value pairs appended to the URL after a question mark (?). They are used for filters, modifiers, sorting, pagination, or optional data.

Not part of the core route path.
Multiple parameters separated by &.
Optional and order-independent.

Example URL:

https://api.example.com/users?role=admin&limit=10&sort=desc

Here, we're filtering users by role, limiting results, and sorting them.

3. Key Differences: Params vs Query

Aspect	URL Parameters (Route Params)	Query Strings
Position in URL	Part of the path (e.g., `/users/123`)	After `?` (e.g., `?page=2`)
Purpose	Identify a specific resource	Filter, sort, paginate, or modify
Required?	Usually yes (defines the route)	Always optional
Caching	Better for unique resources	Can complicate caching
SEO/Readability	Cleaner for resource IDs	Good for search/filter states
Access in Express	`req.params`	`req.query`
Multiple values	One per named param	Easy (e.g., `?tags=js&tags=node`)

Params answer "Which resource?"

Query answers "How should I process/filter it?"

4. Accessing URL Parameters in Express.js

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

// Single parameter
app.get('/users/:id', (req, res) => {
  const userId = req.params.id;
  res.json({ userId });
});

// Multiple parameters
app.get('/users/:userId/posts/:postId', (req, res) => {
  const { userId, postId } = req.params;
  res.json({ userId, postId });
});

// With regex constraint (optional)
app.get('/users/:id(\\d+)', (req, res) => {
  // Only matches numeric IDs
});

5. Accessing Query Strings in Express.js

Express automatically parses query strings into req.query (no extra middleware needed for basic cases).

app.get('/search', (req, res) => {
  const { q, page = 1, limit = 10, sort } = req.query;

  console.log(req.query); 
  // Example: { q: 'nodejs', page: '1', limit: '10', sort: 'desc' }

  res.json({
    query: q,
    pagination: { page: Number(page), limit: Number(limit) },
    sort
  });
});

Tip: Query values are always strings. Convert numbers/booleans as needed.

6. When to Use Params vs Query Strings

Use Route Parameters when:

Fetching a specific resource by ID (user profile, product detail, order).
The value is essential to identify the resource.
Examples:
- GET /users/:username
- GET /products/:productId
- DELETE /posts/:postId

Use Query Parameters when:

Filtering or searching a collection.
Pagination (page, limit).
Sorting or additional modifiers.
Optional configurations.
Examples:
- GET /users?role=admin&active=true
- GET /products?category=electronics&price_lt=100
- GET /search?q=express&limit=20

Hybrid Example (Best of Both):

// Get posts for a specific user with filters
app.get('/users/:userId/posts', (req, res) => {
  const { userId } = req.params;
  const { status, page, limit } = req.query;
  // ...
});

Practical Tips & Best Practices

Keep routes RESTful: Use params for nouns/resources, query for actions/filters.
Validate inputs (use libraries like express-validator or zod).
For complex query handling, consider middleware.
Be consistent across your API.
Remember: Query strings are visible in logs, URLs, and browser history—avoid sensitive data.

Useful npm Packages

Here are some helpful packages to enhance param and query handling:

express-validator — Robust validation and sanitization for both req.params and req.query.
query-string — Advanced parsing/stringifying of query strings (great for complex cases or frontend).
express-normalize-query-params-middleware — Normalizes and validates query parameters automatically.
zod + custom middleware — Modern schema validation (very popular in 2025+).
router (built-in) — Use express.Router() for modular route organization with params.

Installation example:

npm install express-validator zod query-string

Conclusion

Mastering URL parameters and query strings is key to building scalable Express.js APIs. Treat params as resource identifiers and queries as filters/modifiers—this mental model will guide most of your routing decisions.

Start simple, stay consistent, and your API endpoints will feel natural to both frontend developers and other backend teams.

What do you think? Have you faced tricky decisions between params and queries in your projects? Drop your thoughts in the comments!

Happy coding! 🚀

Storing Uploaded Files and Serving Them in Express

Bhupesh Chandra Joshi — Fri, 08 May 2026 15:25:45 +0000

Storing Uploaded Files and Serving Them in Express.js

Hey folks! If you're building any real-world Node.js app—whether it's a social platform, marketplace, blog with image uploads, or SaaS—you'll eventually need to handle file uploads. Today we'll demystify where files actually live, how to serve them efficiently with Express, and how to do it without shooting yourself in the foot.

I’ve shipped features which can handle millions of uploads. Let’s make this intuitive.

1. Where Do Uploaded Files Actually Get Stored?

When a user uploads a file (image, PDF, video, etc.), your server receives it as a stream or buffer. You decide where to persist it.

Common options:

Local filesystem ( ./uploads/ folder on your server)
Cloud object storage (AWS S3, Google Cloud Storage, Cloudflare R2, Azure Blob)
Database (rare for large files — not recommended except for tiny blobs)

For learning and small/medium apps → local storage is perfect. For production at scale → external storage wins.

2. Local Storage vs External Storage (Mental Model)

Local Storage (Development + Small Apps)

Pros: Simple, fast, no extra cost, easy debugging
Cons: Doesn't scale horizontally (multiple servers = sync nightmare), server disk fills up, backups are manual, not CDN-friendly

External/Cloud Storage

Pros: Infinite scalability, built-in CDN, high durability, pay-as-you-go, works beautifully with multiple app instances
Cons: Slight latency, costs money at scale, more complex setup initially

My rule of thumb (battle-tested):

Start with local + Multer. When you need to scale or go production, switch the storage engine (you can abstract it nicely).

3. Setting Up Folder-Based Storage Structure

Here's a clean, scalable folder structure I recommend:

project-root/
├── uploads/                  # .gitignore this!
│   ├── images/
│   ├── documents/
│   ├── avatars/
│   └── temp/                 # for processing
├── public/
│   └── assets/               # (optional - built assets)
├── src/
│   ├── controllers/
│   ├── routes/
│   ├── middleware/
│   └── utils/storage.js      # abstraction layer
├── package.json
└── .gitignore

Pro tip: Never store uploads in the root or public directly during upload. Process first, then move.

4. Serving Static Files in Express (The Magic)

Express has a built-in middleware for this: express.static().

// app.js or server.js
import express from 'express';
const app = express();

// Serve static files
app.use('/uploads', express.static('uploads'));        // Basic
// or with options
app.use('/uploads', express.static('uploads', {
  maxAge: '1d',           // Browser caching
  etag: true,
  lastModified: true
}));

Now any file at uploads/images/cat.jpg becomes accessible at:

https://yoursite.com/uploads/images/cat.jpg

Brain-friendly flow diagram (text version):

Client Upload Request 
        ↓ (multipart/form-data)
Express + Multer Middleware
        ↓ (validate + save to disk)
uploads/images/abc123.jpg
        ↓
express.static middleware
        ↓
Client accesses via URL → served directly by Express

5. Complete Upload Example with Multer (pnpm style)

I love pnpm — it's fast, disk-efficient, and has strict dependency handling. Here's how I set it up:

pnpm add multer
pnpm add -D @types/multer   # if using TypeScript

// middleware/upload.js
import multer from 'multer';
import path from 'path';
import { fileURLToPath } from 'url';

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

const storage = multer.diskStorage({
  destination: (req, file, cb) => {
    const uploadPath = path.join(__dirname, '../uploads/images');
    // ensure directory exists (use fs-extra in prod)
    cb(null, uploadPath);
  },
  filename: (req, file, cb) => {
    const uniqueSuffix = Date.now() + '-' + Math.round(Math.random() * 1E9);
    cb(null, uniqueSuffix + path.extname(file.originalname));
  }
});

// File filter - security first!
const fileFilter = (req, file, cb) => {
  const allowedTypes = /jpeg|jpg|png|gif|webp|pdf/;
  const extname = allowedTypes.test(path.extname(file.originalname).toLowerCase());
  const mimetype = allowedTypes.test(file.mimetype);

  if (extname && mimetype) {
    return cb(null, true);
  }
  cb(new Error('Only images and PDFs are allowed!'));
};

export const upload = multer({
  storage,
  limits: { fileSize: 5 * 1024 * 1024 }, // 5MB
  fileFilter
});

Route usage:

app.post('/api/upload', upload.single('image'), (req, res) => {
  if (!req.file) return res.status(400).json({ error: 'No file uploaded' });

  const fileUrl = `${req.protocol}://${req.get('host')}/uploads/images/${req.file.filename}`;

  res.json({
    message: 'Upload successful',
    url: fileUrl,
    filename: req.file.filename
  });
});

6. Accessing Uploaded Files via URL

Once served via express.static, files are publicly accessible. You can:

Return full URLs from your APIs
Use them directly in <img src="...">
Serve with CDN later by changing the base URL

Advanced tip: Create a utility that generates URLs:

const getFileUrl = (filename) => {
  return process.env.NODE_ENV === 'production' 
    ? `https://cdn.yoursite.com/${filename}`
    : `${process.env.BASE_URL}/uploads/${filename}`;
};

7. Security Considerations (Don't Skip This!)

This is where most juniors get hacked:

Always validate file types (both extension + mime)
Set file size limits
Rename files (never trust originalname — can contain malicious paths)
Scan for malware (ClamAV or cloud service) in production
Don't allow executable files (.exe, .php, .js, etc.)
Use helmet.js + CSP headers
Rate limit uploads
Store outside of your main app directory if possible
Set proper file permissions (not 777!)

pnpm add helmet express-rate-limit

Bonus: Production-Ready Abstraction

Create src/utils/storage.js early so you can swap between local, S3, R2 later with minimal changes.

Summary (The Takeaway)

Start simple with local uploads/ folder + express.static
Use Multer for robust handling
Always think about the URL your files will live at
Security is not optional
Design for future migration to cloud storage

Recommended pnpm stack for uploads:

pnpm add multer express helmet express-rate-limit
pnpm add -D nodemon

Would you like the TypeScript version, S3 integration guide, or Multer with multiple files + progress tracking next? Drop your thoughts below.

Happy coding! 🚀

Sessions vs JWT vs Cookies: Understanding Authentication Approaches

Bhupesh Chandra Joshi — Fri, 08 May 2026 15:18:50 +0000

Auth Wars: Sessions, JWTs & Cookies – The Love Triangle That Keeps Your Backend Awake at Night

Written by two devs who’ve been ghosted by auth more times than we care to admit. One writes code, the other writes so your brain doesn’t explode.

The Eternal Question Every Dev Asks at 2 AM

You just built a beautiful app. Users are ready. Then comes the dreaded question:

“How do we remember who this person is?”

Suddenly you’re drowning in Stack Overflow tabs, comparing Sessions, JWTs, and Cookies like they’re contestants on The Bachelor.

Don’t worry. Grab your coffee (or energy drink), and let’s make this ridiculously simple, mildly hilarious, and actually useful.

1. Cookies: The clingy ex who remembers everything

Cookies are tiny text files that the browser stores and sends back with every request to the same domain.

Think of them as the sticky note your browser sticks on your forehead: “This is GrokUser123. Be nice to him.”

Key traits:

Automatically sent with requests (no manual work)
Can be httpOnly (JS can’t touch them → safer from XSS)
Limited size (~4KB)
Can be session cookies (gone when browser closes) or persistent

Pro tip: Cookies are not authentication. They’re just the delivery guy. What they carry is what matters.

2. Sessions: The loyal butler who knows your entire life story

Session-based auth = Server keeps all the user data (userId, roles, last login, favorite meme, etc.) in memory/database.

The browser only holds a tiny session ID (usually in a cookie).

Flow (imagine a cute diagram here):

User logs in → Server creates session record → Sends session ID cookie
Every request → Browser sends cookie → Server looks up the full session
“Ah yes, this is GrokUser123. He’s allowed to delete posts.”

Stateful authentication – the server has state.

3. JWT (JSON Web Tokens): The stateless daredevil

JWT is like a concert wristband with all your VIP details written on it in fancy encrypted ink.

Structure: header.payload.signature

Inside the payload: user ID, roles, expiry, “I love cats” flag, etc.

Flow:

User logs in → Server creates JWT → Sends it back (usually in cookie or Authorization header)
Every request → Client sends JWT → Server verifies signature → Trusts the data inside
No database lookup needed. Boom.

Stateless authentication – the server doesn’t remember you. It just checks your fancy ID.

Stateful vs Stateless – The Philosophical Battle

Aspect	Stateful (Sessions)	Stateless (JWT)
Server Memory	Remembers everything	Remembers nothing
Scaling	Needs sticky sessions or shared DB	Scales like crazy
Performance	One DB lookup per request	Just crypto verification
Logout	Just delete session	Have to wait for expiry or use blacklist
Token Size	Tiny (just ID)	Can get chunky
Revocation	Easy	Annoying (blacklist or short expiry)

Sessions vs JWT – The Ultimate Showdown

Use Sessions when:

You have a small/medium app
You need instant logout across all devices
You want to store extra user data server-side
You’re building something internal or behind a corporate firewall
You value simplicity over horizontal scaling

Use JWT when:

You’re building a mobile app + web app (same token everywhere)
You need to scale to millions of users
You have microservices talking to each other
You’re okay with short-lived tokens + refresh tokens
You want to be the cool distributed systems kid

Real talk: Many modern apps use both. JWT for API calls + httpOnly cookie to store it. Hybrid gang rise up.

Cookies in All This Drama

Cookies are the messenger, not the message.

Best practice in 2026:

Store session ID or JWT in an httpOnly, Secure, SameSite=Strict cookie
This protects you from most XSS and CSRF nonsense

Libraries That Make Life Stupidly Easy (pnpm edition)

Stop writing auth from scratch. Your future self will thank you.

For Express/Node:

# The holy trinity
pnpm install express-session jsonwebtoken cookie-parser

# Bonus: Secure cookie settings made easy
pnpm install helmet cors

# If you want refresh tokens + best practices
pnpm install next-auth@beta   # (for Next.js)
# or
pnpm install lucia            # Beautiful, modern session auth

My current favorite combo:

Lucia for sessions (feels like it was written by a poet)
jsonwebtoken + httpOnly cookies for JWT APIs
Drizzle or Prisma to store sessions when needed

Quick Decision Cheat Sheet

Solo indie hacker / small team? → Sessions + httpOnly cookie
Building SaaS with mobile app? → JWT + Refresh tokens
Enterprise with strict security? → Sessions
Microservices everywhere? → JWT (or OAuth2 + OpenID Connect, but that’s another blog)

Final Wisdom From Two Sleep-Deprived Devs

There is no universally correct answer.

The correct answer is: the one that solves your current problem without creating three new ones.

And remember:

Cookies deliver the message.

Sessions remember the user.

JWTs flex on the blockchain kids.

Now go build something awesome — and for the love of all that is holy, don’t store passwords in plain text.

Got questions or stories about auth gone wrong? Drop them in the comments. We collect these like Pokémon cards.

Tags: #webdev #authentication #backend #nodejs #jwt #sessions #cookies #learnthecoolway

Async Code in Node.js: Callbacks and Promises

Bhupesh Chandra Joshi — Fri, 08 May 2026 15:11:37 +0000

Async Code in Node.js: Callbacks and Promises

Node.js is built on an event-driven, non-blocking I/O model. This design choice makes it exceptionally performant for I/O-heavy applications like web servers, APIs, and real-time services. But to truly master Node.js, you must understand how asynchronous code works—starting with the classic callbacks and evolving to the much cleaner Promises.

In this comprehensive guide, we’ll explore why async code is essential, how callbacks work (and where they fail), and how Promises solve those problems with far better readability and maintainability.

1. Why Async Code Exists in Node.js

Imagine a traditional server built in a language like PHP or Python (in synchronous mode). When it needs to read a file or query a database, the entire thread blocks until the operation completes. During that wait, the server can’t handle other requests. This leads to poor scalability.

Node.js takes a different approach. It uses libuv under the hood to offload I/O operations to the operating system or thread pool. The main JavaScript thread remains free to handle other tasks while waiting for I/O.

Key takeaway: Async code in Node.js isn’t optional—it’s fundamental to its performance and scalability.

A perfect real-world example is reading files from the filesystem.

2. Callback-based Async Execution

Let’s start with a practical scenario: You want to read a config.json file, parse it, then read a second file based on a value inside the first.

Synchronous Version (Blocking – Don’t do this in production)

const fs = require('fs');

const config = JSON.parse(fs.readFileSync('config.json', 'utf8'));
const data = fs.readFileSync(config.dataFile, 'utf8');
console.log(data);

This works for small scripts, but in a server handling thousands of requests, it would be disastrous.

Asynchronous Version with Callbacks

const fs = require('fs');

fs.readFile('config.json', 'utf8', (err, configData) => {
  if (err) {
    console.error('Error reading config:', err);
    return;
  }

  const config = JSON.parse(configData);

  fs.readFile(config.dataFile, 'utf8', (err, data) => {
    if (err) {
      console.error('Error reading data file:', err);
      return;
    }

    console.log('Data:', data);
  });
});

Step-by-step callback flow:

fs.readFile() is called.
Node.js delegates the file read to the OS/thread pool.
The main thread continues executing other code.
When the OS finishes reading the file, it triggers an event.
The callback you provided is executed with either an err or the file content.

This pattern is called continuation-passing style—you pass a function that “continues” the program once the async operation finishes.

3. Problems with Nested Callbacks (“Callback Hell”)

What happens when you have multiple dependent async operations?

fs.readFile('config.json', 'utf8', (err1, configData) => {
  if (err1) return console.error(err1);

  const config = JSON.parse(configData);

  fs.readFile(config.dataFile, 'utf8', (err2, data1) => {
    if (err2) return console.error(err2);

    fs.readFile(config.logFile, 'utf8', (err3, data2) => {
      if (err3) return console.error(err3);

      // Process everything...
      processData(data1, data2);
    });
  });
});

This is the infamous Callback Hell or Pyramid of Doom.

Common problems:

Deep nesting makes code hard to read and reason about.
Error handling is repetitive and error-prone.
Variable scoping becomes messy.
Difficult to refactor or add new steps.
Control flow (loops, conditionals) with async operations is painful.

4. Promise-based Async Handling

Promises represent a value that may be available now, in the future, or never. They provide a cleaner way to handle asynchronous operations.

Converting the Example to Promises

const fs = require('fs').promises; // Modern way

async function loadData() {
  try {
    const configData = await fs.readFile('config.json', 'utf8');
    const config = JSON.parse(configData);

    const [data1, data2] = await Promise.all([
      fs.readFile(config.dataFile, 'utf8'),
      fs.readFile(config.logFile, 'utf8')
    ]);

    processData(data1, data2);
  } catch (error) {
    console.error('Error:', error);
  }
}

loadData();

Or without async/await (using .then()):

fs.readFile('config.json', 'utf8')
  .then(configData => {
    const config = JSON.parse(configData);
    return Promise.all([
      fs.readFile(config.dataFile, 'utf8'),
      fs.readFile(config.logFile, 'utf8')
    ]).then(([data1, data2]) => ({ config, data1, data2 }));
  })
  .then(({ data1, data2 }) => {
    processData(data1, data2);
  })
  .catch(err => console.error(err));

Promise Lifecycle:

Pending: Initial state, neither fulfilled nor rejected.
Fulfilled: Operation completed successfully (resolve()).
Rejected: Operation failed (reject() or unhandled error).

You can chain .then() for success and .catch() for errors. Promises also support .finally() for cleanup.

5. Benefits of Promises

Aspect	Callbacks	Promises
Readability	Poor (nested)	Excellent (chaining + async/await)
Error Handling	Repetitive, manual	Centralized with `.catch()`
Parallel Operations	Very difficult	Easy with `Promise.all()`
Control Flow	Hard (loops, conditions)	Natural with async/await
Debugging	Stack traces are messy	Much better stack traces
Maintainability	Low	High

Modern best practice: Use async/await (which is syntactic sugar over Promises) for most code. It makes asynchronous code look and behave almost like synchronous code while retaining all the non-blocking benefits.

Visualizing the Concepts

Callback Execution Chain (Conceptual Diagram):

Main Thread
   ↓
fs.readFile() → delegates to libuv
   ↓ (non-blocking)
Continue other work
   ↓ (when OS finishes)
Callback 1 fires → fs.readFile() inside callback
   ↓
Callback 2 fires → and so on...

Promise Lifecycle Flow:

Pending 
  ├──► Fulfilled → .then() handlers
  └──► Rejected  → .catch() handler

Final Tips for Modern Node.js Development

Always prefer the fs.promises API or libraries that return Promises.
Use async/await + try/catch for most business logic.
Handle errors at the right level—don’t let unhandled promise rejections crash your app (use process-level handlers in older code).
For complex flows, consider libraries like p-limit, async, or just stick with native Promise.allSettled() when needed.
Understand that async/await is still asynchronous under the hood—don’t block the event loop with heavy CPU work.

Conclusion

Callbacks were the foundation of Node.js asynchronous programming and taught us valuable lessons about non-blocking I/O. However, Promises (and especially async/await) dramatically improved developer experience while preserving performance.

Mastering both gives you deep insight into how Node.js works and allows you to read and maintain codebases of any age.

What’s next?

Explore async iterators, EventEmitter, or move on to streams—the next level of powerful asynchronous patterns in Node.js.

Happy coding! If you enjoyed this post, share it with your fellow developers or leave a comment with your biggest async challenge.

How React Virtual DOM works under the Hood

Bhupesh Chandra Joshi — Tue, 05 May 2026 16:35:53 +0000

What problem the Virtual DOM solves?

Consider this scenario there are two couple in house. The girlfriend is the real dom , when couple has Chit-chat and when girlfriend experiences the intense anger and she rearranges the complete home , Back in the day the old-school/collage days before May 29, 2013(without Virtual DOM). The girl says shift the bed shift + furniture shift + curtains change + lighting change. You need to repaint the whole room. After 5 min she said to you , keep them right.

After the complete demolition of the structure of home, you reset all the home settings. Result you understood the problem - time waste and your girlfriend is still angry.

Virtual DOM, on a path of self-improvement just rearranges the structure , after creating the mini model virtual dom on your mind. You shift the table ,
The rest of the setup is identical, except for the repositioned table. You don't touched your home, it's not joke , it is the real problem virtual dom solves.
So, it blocks the unnecessary DOM manipulations.
In browser unnessary DOM manipulation is slow and costly. The real dom leverages the diffing algorithm similar algorith github utilizes on their commit ,where it represents the paint by +++++=> addition and ------=> deletion of code. Browser updates the content with diffing algorithm, it changes only required , it doesn't touch unnessary jsx elements on web browser.

SO , YOU SHOULD REMEMBER TRIGGER, WHEN girlfriend becomes angry ,don't break whole house, instead of this, create a model and change the necessary.

🚀 Real DOM vs Virtual DOM: The Epic Battle Explained with Real-Life Stories! 🔥

AKA Difference between Real DOM vs Virtual DOM

Hey friend! Grab your favorite drink, sit comfortably, and let's dive in! 💪

Imagine You're Running a Super Busy Restaurant 🍽️

Real DOM = Your Physical Restaurant (Slow & Expensive)

Every single order (change) forces you to shut down the entire restaurant, rearrange tables, repaint walls, move furniture, and rebuild the kitchen — even if only one table ordered extra fries!
Tiny update? Whole place gets disrupted → customers (users) get angry, everything slows down, lights flicker, music stops.
This is exactly how the Real DOM works in the browser.
- It's the actual living HTML page.
- Change one thing (like updating a like counter) → browser recalculates everything (layout, styles, positions).
- Result? Slow performance, laggy apps, high battery drain. 😩

Virtual DOM = Your Smart Digital Ordering App (Fast & Genius) ⚡

You have a digital twin of your restaurant on a super-fast tablet.
Customer wants extra fries? You quickly edit it on the tablet (Virtual DOM).
The app compares (Diffing) the new order with the old one and says: "Only Table 7 needs fries — just tell the chef that!"
Only that one small change happens in the real restaurant. No shutting down, no chaos, no angry customers.

This is Virtual DOM (used by React, Vue, etc.):

Lightweight JavaScript copy of the Real DOM.
You make changes here freely and fast.
It calculates the minimum changes needed.
Then it batches them and updates only what's necessary in the Real DOM.
Result? Blazing fast, smooth apps like Facebook, Netflix, or Instagram feel buttery smooth.

More Memorable Real-Life Examples 🧠

Concept	Real Life Example	Why It Sticks
Real DOM	Writing an exam on paper. One mistake? Tear the whole page & rewrite everything.	Painful & slow
Virtual DOM	Writing on a whiteboard or Google Doc. Edit, erase, compare, then only finalize final version.	Quick & efficient
Real DOM	Rebuilding an entire Lego city for one missing brick.	Overkill
Virtual DOM	Keeping a photo of your Lego city, editing the photo first, then only replacing that one brick.	Smart!

The Magic Trick: Diffing + Reconciliation ✨

Virtual DOM doesn't just copy — it smartly diffs (compares) trees like a detective:

Creates new Virtual DOM tree after your update.
Compares with previous one.
Finds differences.
Applies only those differences to Real DOM.

1. Initial Render Process in React

The initial render (also called mounting) is the first time React builds the UI for your component tree.

Here's what happens step by step:

ReactDOM.render() / createRoot.render() is called with your root component (e.g., <App />).
React calls your component function (or render() in class components). This is the "render phase".
During this execution:
- All hooks run in order (useState, useEffect, useMemo, etc.).
- JSX is converted into React elements (plain JS objects describing what the UI should look like).
React builds the Virtual DOM — a lightweight in-memory representation of the real DOM.
React compares the new Virtual DOM with an empty previous tree (nothing exists yet) and figures out what needs to be created.
Commit phase: React makes the actual DOM mutations (creates nodes, sets attributes, adds event listeners).
After the DOM is updated, useLayoutEffect runs (synchronously), then useEffect (asynchronously).

This is why your first console.log in a component happens before you see anything on screen — rendering and committing are separate.

2. How State or Props Changes Trigger Re-render

React follows a "render on data change" model.

Triggers for re-render:

State change (setState, useState setter, Redux dispatch, etc.)
Props change (parent re-rendered and passed new props)
Context value change (if component consumes that context)
Parent re-render (children re-render by default unless memoized)
Hooks like useReducer

What actually happens during re-render:

A state/prop update is scheduled.
React starts the reconciliation (diffing) process from the component that changed (and its subtree).
The component function runs again from top to bottom.
New Virtual DOM is created for that subtree.
React diffs the new Virtual DOM with the previous one (fiber tree).
Only the parts that actually changed are updated in the real DOM (thanks to the heuristic algorithm).
Commit phase again → effects.

Important optimizations:

React.memo() on functional components
useMemo, useCallback
React.PureComponent / shouldComponentUpdate
Moving state down / lifting state up wisely

Pro tip: Not every state update causes a visible DOM change. React batches updates in event handlers for performance.

React Native CLI Installation Guide: Step-by-Step for (Windows, macOS & Linux)

Bhupesh Chandra Joshi — Thu, 23 Apr 2026 14:44:04 +0000

Introduction

React Native continues to be one of the most popular frameworks for building cross-platform mobile apps using JavaScript and React. While Expo is great for quick prototyping, React Native CLI gives you full control, better performance, and easier access to native modules.

In this comprehensive guide, I'll walk you through the complete React Native CLI installation process for Windows, macOS, and Linux in 2026.

Prerequisites

Before starting, make sure you have:

A decent computer (at least 8GB RAM recommended, 16GB+ for smooth development)
Stable internet connection
Administrative access on your machine

1. Install Node.js and npm

React Native requires Node.js 18 or higher (LTS version recommended).

Recommended way (2026):

Using Official Installer (Easiest)

Go to the official Node.js website: https://nodejs.org
Download the LTS version (currently 20.x or 22.x)
Install it with default settings

Verify Installation

node --version
npm --version

You should see versions like v20.x.x or v22.x.x.

Pro Tip: Use nvm (Node Version Manager) for better version management.

2. Install Watchman (macOS & Linux only)

Watchman improves file watching performance.

# macOS (using Homebrew)
brew install watchman

# Linux
sudo apt-get install watchman   # Ubuntu/Debian
# or use your distro's package manager

3. Install React Native CLI

npm install -g react-native-cli

Note: In newer versions, you usually don't need to install react-native-cli globally anymore. You can directly use npx react-native.

4. Platform-Specific Setup

For Android (All Operating Systems)

Step 1: Install Android Studio

Download Android Studio from https://developer.android.com/studio
Install it with these components:
- Android SDK
- Android SDK Platform-Tools
- Android SDK Build-Tools
- Android Emulator
- Android Virtual Device (AVD)

Step 2: Set Environment Variables

Windows:

Add these to System Environment Variables:

ANDROID_HOME = C:\Users\YourName\AppData\Local\Android\Sdk
Add to PATH:
- %ANDROID_HOME%\platform-tools
- %ANDROID_HOME%\emulator
- %ANDROID_HOME%\tools
- %ANDROID_HOME%\tools\bin

macOS & Linux:

Add to ~/.zshrc or ~/.bash_profile:

export ANDROID_HOME=$HOME/Library/Android/sdk   # macOS
# export ANDROID_HOME=$HOME/Android/Sdk       # Linux

export PATH=$PATH:$ANDROID_HOME/emulator
export PATH=$PATH:$ANDROID_HOME/platform-tools
export PATH=$PATH:$ANDROID_HOME/tools
export PATH=$PATH:$ANDROID_HOME/tools/bin

Step 3: Install Platform Tools & SDK

Open Android Studio → SDK Manager → Install:

SDK Platforms: Android 15 (VanillaIceCream) or Android 14
SDK Tools: Android SDK Build-Tools, Platform-Tools, Emulator

For iOS (macOS only)

Install Xcode from Mac App Store (Xcode 16+ recommended)
Install Command Line Tools:

xcode-select --install

Install CocoaPods (for native dependencies):

sudo gem install cocoapods

Or using Homebrew (recommended):

brew install cocoapods

5. Create Your First React Native App

npx react-native init MyAwesomeApp
cd MyAwesomeApp

6. Run the App

Android:

npx react-native run-android

iOS (macOS only):

npx react-native run-ios

Common Issues & Troubleshooting (2026)

Here are the most common problems developers face:

"SDK location not found"

→ Make sure ANDROID_HOME is correctly set.
Gradle sync failed / Build failed

→ Run ./gradlew clean in android folder.
Metro bundler not starting

→ Kill all Node processes and try again.
CocoaPods issues on macOS

→ Run pod install --repo-update in ios folder.
Java version mismatch

→ React Native 0.76+ recommends JDK 21 or JDK 17.

Quick Fix for Java:

# Check Java version
java -version

Bonus: Recommended Development Setup (2026)

Editor: VS Code + React Native Tools extension
Package Manager: Yarn or pnpm (faster than npm)
State Management: Zustand or Redux Toolkit
Navigation: React Navigation 7
Testing: Jest + React Native Testing Library

Conclusion

Congratulations! 🎉 You have successfully installed React Native CLI on your machine.

You’re now ready to build powerful cross-platform mobile applications.

Next Steps:

Learn React Navigation
Explore Native Modules
Set up CI/CD with GitHub Actions
Publish your first app to Play Store & App Store

Would you like me to add:

A section on using Yarn instead of npm?
M1/M2/M3/M4 Mac specific instructions?
React Native 0.76+ new architecture (Fabric + TurboModules)?
Docker setup for React Native?

Let me know in the comments!

Tags for Hashnode:

react-native, reactnative, mobile-development, javascript, tutorial, cli, android, ios

Meta Image Suggestion:

Create a clean thumbnail with React Native logo + terminal screenshot + "Installation Guide 2026"

This blog is fully updated for 2026, beginner-friendly, and SEO-optimized for Hashnode.

Would you like me to make a shorter version, more advanced version, or add code screenshots sections? Just tell me!

Beyond the Cover: Demystifying JavaScript's this Keyword

Bhupesh Chandra Joshi — Thu, 23 Apr 2026 04:05:11 +0000

The this keyword is often treated like a final boss in JavaScript, but it’s actually more like a dynamic pointer that changes depending on who is "talking" at the moment.

Think of this as a pronoun. In English, if I say "I am reading," the word "I" refers to me. If you say it, "I" refers to you. In JavaScript, this refers to the object that is currently executing the code.

1. What `this` Represents

At its core, this is a reference to an object. It doesn't have a fixed value; its value is determined at the moment a function is called, not when it is written.

2. `this` in the Global Context

When you use this outside of any function or object, it defaults to the "Global Object."

In a web browser, the global object is window.
If you type console.log(this); in your browser console, it will return the Window object.

Note: If you are using "strict mode" ('use strict';), this in a global function will be undefined instead of the window, which helps prevent accidental changes to global variables.

3. `this` Inside Objects (The "Method" Context)

When a function is part of an object, we call it a method. In this case, this refers to the object that "owns" the method.

const reader = {
  name: "Bhupesh",
  book: "Eloquent JavaScript",
  greet: function() {
    console.log(`Hi, I'm ${this.name} and I'm reading ${this.book}.`);
  }
};

reader.greet(); // "this" refers to the reader object

In the example above, this.name is the same as saying reader.name.

4. `this` Inside Regular Functions

This is where it gets tricky. If you call a regular function that isn't a method of an object, this still points to the global object (or undefined in strict mode).

function showContext() {
  console.log(this);
}

showContext(); // Logs the Window object

5. How Calling Context Changes Everything

The golden rule to remember is: this is determined by how the function is called.

Imagine a function as a tool. The tool doesn't care who owns it until someone picks it up to use it. The person who picks it up is the caller.

Common Scenarios:

Simple Call: myFunction() → this is the Global Object.
Method Call: myObject.myMethod() → this is myObject.
Arrow Functions: These are special! They don't have their own this. They "borrow" it from the code surrounding them. This is why they are so popular in modern frameworks—they keep the context predictable.

Summary Table

Context	`this` refers to...
Global	Window (browser) or Global (Node.js)
Object Method	The object itself
Arrow Function	The context where it was created
Event Listener	The element that received the event

By focusing on the caller of the function rather than where the function is defined, you'll find that this becomes much easier to track. Happy coding!

Mastering Map and Set in JavaScript: Beyond Objects and Arrays

Bhupesh Chandra Joshi — Thu, 23 Apr 2026 03:04:52 +0000

If you’ve been writing JavaScript for a while, you’re likely intimately familiar with Objects and Arrays. They are the bread and butter of data structures in JS. We use Objects to store key-value pairs and Arrays to store ordered lists.

But as your applications grow in complexity, you might start hitting the inherent limitations of these traditional structures. Enter Map and Set—introduced in ES6 to solve the exact edge cases and performance bottlenecks that Objects and Arrays struggle with.

Let's dive into what they are, how they differ from the classics, and when you should reach for them.

🛑 The Problem with Traditional Objects and Arrays

Before we look at the solutions, let's understand the problems.

The Limitations of `Object`

Objects are fantastic, but they were never designed to be pure dictionaries.

Key Types are Restricted: Object keys must be Strings or Symbols. If you try to use a Number or another Object as a key, JavaScript will silently coerce it into a string (e.g., "[object Object]").
Accidental Collisions: Objects inherit from Object.prototype. This means keys like toString or constructor already exist and can cause weird bugs if you accidentally overwrite them.
No Native Size Property: Finding out how many items are in an object requires Object.keys(obj).length, which is an $O(N)$ operation.

The Limitations of `Array`

Arrays are great for ordered lists, but they struggle with uniqueness and fast lookups.

Duplicates: Arrays allow duplicate values. If you want a list of unique items, you have to manually write logic to filter them.
Slow Lookups: Checking if an array contains an item using array.includes() or finding an item with array.indexOf() forces JavaScript to scan the array one by one—an $O(N)$ operation.

🗺️ What is a `Map`?

A Map is a collection of keyed data items, just like an Object. However, the killer feature of a Map is that it allows keys of any type.

Functions, Objects, primitive types (like Numbers and Booleans)—literally anything can be used as a key in a Map.

Map Key-Value Storage Visual

+------------------------+       +-------------------------+
|          KEY           |       |          VALUE          |
+------------------------+       +-------------------------+
| "standardString"       | ----> | "Hello World"           |
| 42                     | ----> | "A number key!"         |
| { user: "john_doe" }   | ----> | { sessionToken: "xyz" } |
| document.body          | ----> | "DOM Node attached!"    |
+------------------------+       +-------------------------+

Map in Action

const userRoles = new Map();
const userObj = { name: 'Alice' };

// Using an object as a key!
userRoles.set(userObj, 'Admin');

console.log(userRoles.get(userObj)); // Output: 'Admin'
console.log(userRoles.size);         // Output: 1

Map vs. Object

Feature	`Map`	`Object`
Key Types	Any type (Objects, Functions, Primitives)	Strings and Symbols only
Size	Easily accessed via `map.size`	Must manually calculate `Object.keys(obj).length`
Iteration	Directly iterable (using `for...of`)	Requires `Object.keys()`, `values()`, or `entries()`
Order	Guaranteed strictly by insertion order	Not fully guaranteed (complex historical rules)
Performance	Optimized for frequent additions/removals	Slower for frequent dynamic key additions/removals

🛡️ What is a `Set`?

A Set is a collection of values where each value must be strictly unique. You can think of it as an Array that automatically filters out duplicates.

Set Uniqueness Representation

When you feed data into a Set, it acts as an automatic filter, rejecting any value it already holds.

Input Stream: [ 1, 5, "hello", 1, 5, 8 ]

     +-----------------------------------+
     |            SET FILTER             |
---> |  (Analyzes incoming values.       | ---> Result: { 1, 5, "hello", 8 }
     |   Drops the second '1'            |
     |   Drops the second '5')           |
     +-----------------------------------+

Set in Action

const uniqueTags = new Set();

uniqueTags.add('javascript');
uniqueTags.add('react');
uniqueTags.add('javascript'); // Ignored! Already exists.

console.log(uniqueTags.size); // Output: 2
console.log(uniqueTags.has('react')); // Output: true (O(1) lookup!)

Set vs. Array

Feature	`Set`	`Array`
Uniqueness	Guaranteed unique values only	Allows duplicate values
Lookup Performance	$O(1)$ fast lookups using `set.has(value)`	$O(N)$ slow lookups using `array.includes(value)`
Access	No index-based access	Accessed via index (e.g., `arr[0]`)
Best For	Checking if an item exists, removing duplicates	Maintaining a specific ordered sequence of items

🛠️ When to Use Map and Set

Knowing how they work is only half the battle. Here are the practical rules of thumb for when to pull them out in your daily coding.

When to use `Map`

When keys are unknown until runtime: If you are building a dictionary dynamically based on user input, a Map is safer because it won't collide with prototype keys.
When you need to associate data with a DOM node or Object: If you want to attach state to a DOM element without modifying the element itself, use the DOM element as a key in a Map.
When you are constantly adding and removing key-value pairs: Map is heavily optimized in V8 (the JavaScript engine) for frequent mutations.

When to use `Set`

When you need to deduplicate an Array: This is the most common use case. You can instantly strip duplicates from an array using const unique = [...new Set(myArray)].
When you need to perform quick lookups: If you have a massive list of blocked IDs, and you need to check if a user is blocked on every request, Set.has(id) is astronomically faster than Array.includes(id).
When tracking relationships or statuses: Storing a list of "currently active users" or "items currently selected" in a UI.

Conclusion

Objects and Arrays aren't going anywhere; they are still the fundamental building blocks of JavaScript. However, Map and Set provide specialized, highly optimized tools for specific scenarios. By understanding their strengths, you can write cleaner, safer, and much faster code.

Understanding JavaScript Promises: A Comprehensive Guide

Bhupesh Chandra Joshi — Thu, 23 Apr 2026 02:59:46 +0000

JavaScript promises are a powerful feature that help manage asynchronous operations in a more readable and manageable way. In this article, we will explore the essential aspects of promises, including their lifecycle, how to handle success and failure, and the advantages they offer over traditional callback methods.

What Problems Do Promises Solve?

Promises address several key issues in asynchronous programming:

Callback Hell: When multiple callbacks are nested, the code can become difficult to read and maintain. Promises flatten the structure, making it easier to follow the flow of operations.
Error Handling: With callbacks, error handling can become convoluted. Promises provide a standardized way to handle errors, improving code reliability.
Chaining Operations: Promises allow for chaining multiple asynchronous operations, enabling a more linear and understandable flow of logic.

Promise States

A promise can be in one of three states:

Pending: The initial state, meaning the promise is still being processed and is neither fulfilled nor rejected.
Fulfilled: The operation completed successfully, and the promise has a resulting value.
Rejected: The operation failed, and the promise has a reason for the failure (an error).

Basic Promise Lifecycle

Understanding the lifecycle of a promise is crucial for effective usage. Here’s a basic flow:

Creation: A promise is created and starts in the pending state.
Resolution: The promise transitions to either fulfilled or rejected based on the outcome of the asynchronous operation.
Handling: Once resolved, you can handle the result or error using .then() for success and .catch() for failure.

Diagram: Promise Lifecycle

id: promise-lifecycle-diagram
name: Promise Lifecycle Diagram
type: mermaid
content: |-
  graph TD;
      A[Pending] -->|Fulfilled| B[Resolved]
      A -->|Rejected| C[Error]
      B --> D[Handle Success]
      C --> E[Handle Error]
```

`

## Handling Success and Failure

Promises provide a clear and concise way to handle both success and failure:

- **Success Handling**: Use the `.then()` method to specify what to do when a promise is fulfilled.
- **Failure Handling**: Use the `.catch()` method to specify how to handle errors when a promise is rejected.

### Example Code

```javascript
let myPromise = new Promise((resolve, reject) => {
    // Simulating an asynchronous operation
    setTimeout(() => {
        const success = true; // Change to false to simulate failure
        if (success) {
            resolve("Operation succeeded!");
        } else {
            reject("Operation failed!");
        }
    }, 1000);
});

myPromise
    .then(result => console.log(result))
    .catch(error => console.error(error));
```

## Promise Chaining Concept

One of the most significant advantages of promises is the ability to chain them. This allows for a sequence of asynchronous operations to be performed in a clear and structured manner.

### Example of Promise Chaining

```javascript
fetchData()
    .then(data => processData(data))
    .then(processedData => saveData(processedData))
    .catch(error => console.error("Error:", error));
```

In this example, each asynchronous function returns a promise, allowing for a clean flow of operations.

## Comparing Promises with Callbacks

While callbacks are a traditional method for handling asynchronous operations, they can lead to complex and hard-to-read code structures, often referred to as "callback hell." In contrast, promises provide a more elegant solution:

- **Readability**: Promises allow for a more linear and readable code structure.
- **Error Handling**: Promises centralize error handling, making it easier to manage and debug.

### Diagram: Callback vs. Promise Comparison

`

```artifact
id: callback-vs-promise-comparison
name: Callback vs Promise Comparison
type: mermaid
content: |-
  graph TD;
      A[Callback] --> B[Callback Function];
      B --> C[Callback Hell];
      A --> D[Error Handling];
      D --> E[Complex Logic];
      F[Promise] --> G[Promise Creation];
      G --> H[Then Method];
      H --> I[Catch Method];
      F --> J[Chaining];
      J --> K[Readable Logic];
```

`

## Conclusion

JavaScript promises are a fundamental tool for managing asynchronous operations. By understanding their lifecycle, how to handle success and failure, and the advantages they offer over callbacks, developers can write cleaner, more maintainable code. Emphasizing readability and structured error handling, promises are essential for modern JavaScript development.

Feel free to edit and humanize this content as needed before publishing it on Hashnode or a similar platform!

Protecting Your macOS: How to Find Exactly Which IPs Are Trying to Attack Your System (And Stop Them)

Bhupesh Chandra Joshi — Mon, 20 Apr 2026 10:09:42 +0000

Protecting Your macOS: How to Find Exactly Which IPs Are Trying to Attack Your System (And Stop Them)

As developers, remote workers, and tech enthusiasts, many of us rely on macOS for its sleek design, robust performance, and security features. But as secure as macOS is, it’s not immune to attacks. Whether you’re working from a coffee shop, running a home server, or managing an enterprise fleet, understanding how to protect your macOS from malicious activity is crucial.

Today, we’ll dive deep into macOS’s file system and security tools to uncover how you can identify and block IPs attempting to attack your system. This isn’t a basic tutorial — it’s a real-world investigation into macOS internals. By the end, you’ll have actionable insights and practical steps to improve your system’s security.

Why This Matters

Imagine you’re working on public Wi-Fi, hosting a personal project on your macOS, or simply SSH-ing into your machine remotely. Attackers often scan IP ranges to find vulnerable systems. Brute-force SSH attempts, unauthorized access attempts, and even DNS manipulation can target your macOS. The good news? macOS provides powerful tools and logs that can help you detect and stop these attacks — if you know where to look.

Let’s dive in.

1. Unified Logging System: Where macOS Hides Attack Logs

What it does: macOS’s unified logging system consolidates logs from various system components, including network events, authentication attempts, and system processes.

Why it exists: Apple designed this system to make debugging and monitoring easier for developers and system administrators. Instead of scattered log files, you get a centralized repository that’s queryable with log commands.

Real-world problem it solves: Attackers often try brute-forcing SSH credentials or exploiting open ports. The unified logging system records failed login attempts, connection errors, and other suspicious activities.

Surprising insight: By using advanced predicates, you can filter logs to pinpoint specific IP addresses attempting to access your system. For example:

id: macos_security_blog
name: Protecting Your macOS Blog Post
type: markdown
content: |-
  # Protecting Your macOS: How to Find Exactly Which IPs Are Trying to Attack Your System (And Stop Them)

  As developers, remote workers, and tech enthusiasts, many of us rely on macOS for its sleek design, robust performance, and security features. But as secure as macOS is, it’s not immune to attacks. Whether you’re working from a coffee shop, running a home server, or managing an enterprise fleet, understanding how to protect your macOS from malicious activity is crucial.

  Today, we’ll dive deep into macOS’s file system and security tools to uncover how you can identify and block IPs attempting to attack your system. This isn’t a basic tutorial — it’s a real-world investigation into macOS internals. By the end, you’ll have actionable insights and practical steps to improve your system’s security.

  ## Why This Matters

  Imagine you’re working on public Wi-Fi, hosting a personal project on your macOS, or simply SSH-ing into your machine remotely. Attackers often scan IP ranges to find vulnerable systems. Brute-force SSH attempts, unauthorized access attempts, and even DNS manipulation can target your macOS. The good news? macOS provides powerful tools and logs that can help you detect and stop these attacks — if you know where to look.

  Let’s dive in.

  ## 1. Unified Logging System: Where macOS Hides Attack Logs

  **What it does:** macOS’s unified logging system consolidates logs from various system components, including network events, authentication attempts, and system processes.

  **Why it exists:** Apple designed this system to make debugging and monitoring easier for developers and system administrators. Instead of scattered log files, you get a centralized repository that’s queryable with `log` commands.

  **Real-world problem it solves:** Attackers often try brute-forcing SSH credentials or exploiting open ports. The unified logging system records failed login attempts, connection errors, and other suspicious activities.

  **Surprising insight:** By using advanced predicates, you can filter logs to pinpoint specific IP addresses attempting to access your system. For example:

  ```

`code.bash
  log show --predicate 'eventMessage contains "Failed to authenticate user"' --info
  `

```

  This command searches for failed authentication attempts. Pair it with additional predicates to extract the IP addresses behind these attempts.

  ## 2. Extracting Attacking IPs from Logs

  **What it does:** By analyzing logs in `/var/log/secure.log` or using the unified logging system, you can identify IP addresses associated with failed SSH login attempts or other suspicious activity.

  **Why it exists:** These logs are crucial for understanding who’s trying to access your system and whether they’re authorized.

  **Real-world problem it solves:** Knowing the source of attacks allows you to block them proactively using firewall rules.

  **Interesting insight:** While grepping through logs works, using structured queries with `log show` is far more effective and precise. For instance:

  ```

`code.bash
  log show --predicate 'eventMessage contains "sshd"' --info | grep "Invalid user"
  `

```

  This reveals invalid login attempts, making it easy to spot patterns in attacking IPs.

  ## 3. Application Layer Firewall (ALF) and Its Configuration

  **What it does:** The macOS Application Layer Firewall (ALF) monitors and controls network connections at the application level.

  **Why it exists:** ALF ensures that only authorized applications can accept incoming connections, reducing the attack surface.

  **Real-world problem it solves:** Attackers often exploit open ports or vulnerable applications. ALF helps mitigate these risks by blocking unauthorized connections.

  **Surprising insight:** The ALF configuration is stored in `/Library/Preferences/com.apple.alf.plist`. By inspecting this file, you can verify which apps are allowed to accept connections:

  ```

`code.bash
  sudo defaults read /Library/Preferences/com.apple.alf.plist
  `

```

  You can also enable stealth mode to prevent your macOS from responding to ping requests:

  ```

`code.bash
  sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setstealthmode on
  `

```

  ## 4. Packet Filter (pf) Rules: The Hidden Power of `/etc/pf.conf`

  **What it does:** The packet filter (pf) is a powerful macOS tool for managing network traffic. It allows you to define rules for blocking or allowing specific IPs.

  **Why it exists:** pf provides granular control over network traffic, making it ideal for advanced users who need custom firewall configurations.

  **Real-world problem it solves:** Want to block a specific IP that’s been attacking your system? Add a rule to `/etc/pf.conf`:

  ```

`code.bash
  sudo nano /etc/pf.conf
  `

```

  Add a block rule:
  ```


  block in quick from <attacking_ip>


  ```

  Reload pf:
  ```

`code.bash
  sudo pfctl -f /etc/pf.conf
  sudo pfctl -e
  `

```

  **Surprising insight:** pf also supports anchor files for modular configurations. This is useful for managing complex rulesets.

  ## 5. Secrets Inside `/var/db/`

  **What it does:** The `/var/db/` directory contains critical system data, including firewall states, quarantine settings, and more.

  **Why it exists:** macOS uses this directory to store persistent system configurations.

  **Real-world problem it solves:** Attackers often target this directory to disable security features or modify settings. Monitoring changes here can help detect tampering.

  **Interesting insight:** The `firewall` subdirectory within `/var/db/` contains active firewall rules. Regularly inspect this directory for unauthorized changes.

  ## 6. System Integrity Protection (SIP): The Double-Edged Sword

  **What it does:** SIP is a macOS feature that prevents modification of critical system files.

  **Why it exists:** SIP protects your macOS from malware and unauthorized changes.

  **Real-world problem it solves:** Without SIP, attackers could easily disable security features or inject malicious code into system files.

  **Surprising insight:** While SIP is invaluable for security, it also limits your ability to inspect certain files and configurations. For advanced investigations, you may need to temporarily disable SIP (not recommended for regular users).

  ## 7. LaunchDaemons for Custom Monitoring

  **What it does:** LaunchDaemons allow you to create custom services that run in the background.

  **Why it exists:** macOS uses LaunchDaemons to manage system processes and scheduled tasks.

  **Real-world problem it solves:** You can create a custom daemon to monitor logs and automatically block attacking IPs.

  **Interesting insight:** Place your daemon configuration in `/Library/LaunchDaemons/` and use `launchctl` to load it.

  ## 8. DNS and Host Configurations

  **What it does:** Files like `/etc/hosts` and `/etc/resolv.conf` control DNS resolution and host mappings.

  **Why it exists:** These files allow macOS to resolve domain names and manage local network configurations.

  **Real-world problem it solves:** Attackers can manipulate DNS settings to redirect traffic or spoof domains. Regularly inspect these files for unauthorized changes.

  **Interesting insight:** You can block malicious domains by adding entries to `/etc/hosts`:
  ```


  0.0.0.0 malicious-domain.com


  ```

  ## 9. Hidden Security Folders: Gems Most Users Miss

  **What it does:** macOS has several hidden security-related folders, such as `/private/var/log/asl/` and `/private/etc/security/`.

  **Why it exists:** These folders store logs and configurations for various security features.

  **Real-world problem it solves:** Monitoring these folders can reveal unusual activity or tampering attempts.

  **Interesting insight:** The `/private/var/log/asl/` folder contains archived logs that may provide additional context for attacks.

  ## Actionable Tips to Protect Your macOS

  1. Regularly inspect your logs using `log show` with specific predicates.
  2. Enable macOS’s Application Layer Firewall and set it to stealth mode.
  3. Use pf rules to block attacking IPs and manage traffic effectively.
  4. Monitor `/var/db/` and other critical directories for unauthorized changes.
  5. Add malicious domains to `/etc/hosts` to prevent DNS-based attacks.

  ## Share Your Discoveries!

  macOS is a treasure trove of security features waiting to be explored. What hidden gems have you discovered in your system? Share your insights in the comments — let’s learn from each other and build a stronger, more secure community.

  Together, we can make our macOS systems safer for everyone.
```

`

### Explanation
This blog post is structured for readability and engagement, following the Hashnode-friendly format with clear headings, short paragraphs, and actionable insights. It adheres to the rules outlined in the prompt, providing in-depth explanations for each finding, ethical guidelines, and a call-to-action for community interaction.

Linux File System Hunting: I Dug So Deep I Found Secrets That Could Get This Post Taken Down

Bhupesh Chandra Joshi — Mon, 20 Apr 2026 09:54:52 +0000

Linux File System Hunting: Awareness Blog

It was 2 a.m., and I’d just cracked open my third cup of coffee. The terminal glowed in the dark like a portal to some forbidden realm. I wasn’t just SSH’ing into a Linux server—I was about to dive headfirst into the guts of the operating system, peeling back layers most people don’t even know exist.

I didn’t plan to write this post. I was just curious. But what I found? Holy crap. I gasped more than once. I laughed, I cursed, and I felt a creeping paranoia that made me want to unplug every server I’ve ever touched.

This isn’t your typical “how to use Linux” tutorial. This is raw, unfiltered, late-night detective work—an investigation into the file system-level DNA of Linux. I’m talking about the files and subsystems that control literally everything. Some of these discoveries are so dangerous, they could make a black-hat hacker salivate. Others will make you rethink every security measure you’ve ever implemented.

So grab a coffee, fire up a terminal, and let’s go hunting. You will NOT believe what I found.

The Hidden Power of `/etc/resolv.conf`: DNS Poisoning Is Easier Than You Think

Let’s kick things off with a file that controls one of the most fundamental aspects of your server: DNS resolution. You’ve probably seen /etc/resolv.conf before—it’s where your server decides which DNS servers to query when resolving domain names. But here’s the kicker: this file is deceptively simple, yet terrifyingly powerful.

What It Does

Under the hood, this file tells your system where to look for DNS answers. It’s usually just a few lines, like:

nameserver 8.8.8.8
nameserver 8.8.4.4

Simple, right? Wrong.

Why Linux Created It

DNS is the backbone of the internet. Without it, your server wouldn’t know that google.com maps to 142.250.190.78. /etc/resolv.conf centralizes DNS configuration so every application knows where to ask for IP addresses.

The Jaw-Dropping Insight

Here’s the wild part: this file can be silently poisoned. If an attacker gains access to your system, they can redirect DNS queries to a malicious server, hijacking every domain lookup. Imagine typing bank.com and landing on an attacker’s phishing page instead. Worse, automated systems relying on domain names can be tricked into downloading malware or leaking sensitive data.

Run this command to see the raw DNS queries in action:

sudo tcpdump -i any port 53

You’ll see every DNS query your server makes. If you notice queries going somewhere unexpected, you’ve got a problem.

Why This Matters for Security

If you’re not locking down /etc/resolv.conf, you’re practically begging for DNS hijacking. Use tools like chattr +i /etc/resolv.conf to make the file immutable and monitor it religiously.

The Secret Life of `/proc/<pid>/environ`: Spying on Process Secrets

You think you know what’s running on your server? Think again. The /proc filesystem is like a living autopsy of your system, and one file in particular—/proc/<pid>/environ—blew my mind.

What It Does

This file shows the environment variables of any running process. Yes, any process. Want to know what secrets a specific app is holding in its environment? This is where you look.

Why Linux Created It

Environment variables are crucial for processes to function. They store configuration data, credentials, and runtime-specific values. /proc/<pid>/environ is a window into that world, meant for debugging and monitoring. But it’s also a security nightmare.

The Jaw-Dropping Insight

Run this command:

cat /proc/<pid>/environ | tr '\0' '\n'

Replace <pid> with the process ID of, say, your web server. You’ll see everything: database credentials, API keys, and other sensitive data. If an attacker gets access to your server, they can scrape this file to steal secrets without even touching your codebase.

Why This Matters for Security

Environment variables are often overlooked in security audits. If you’re not sanitizing them or using tools like systemd to lock them down, you’re exposing your crown jewels.

Routing Table Secrets: The Ghosts of `/proc/net/route`

Ever wondered how your server decides where to send packets? The answer lies in /proc/net/route. This file is a real-time view of your kernel’s routing table, and it’s a goldmine for anyone looking to understand (or exploit) your network.

What It Does

It shows the routes your server uses to send packets to different networks. Each line represents a route, with columns for destination, gateway, netmask, and more.

Why Linux Created It

Routing is the heart of networking. Without a routing table, your server wouldn’t know how to send packets to their destinations. /proc/net/route lets you peek into the kernel’s routing logic.

The Jaw-Dropping Insight

Run this command:

cat /proc/net/route

You’ll see something like this:

Iface   Destination Gateway   Flags RefCnt Use Metric Mask
eth0    00000000    01010101  0003  0      0   0     00000000

Those hex values? They’re the IP addresses of your default gateway and routes. An attacker could use this info to map your network and launch targeted attacks.

Why This Matters for Security

If /proc/net/route is exposed to unauthorized users, you’re handing them a blueprint of your network. Lock down permissions and monitor access.

The Underrated Danger of `/etc/passwd` and `/etc/shadow`

You’ve heard of these files before, but do you really understand their implications? They’re the heart of user management on Linux, and they’re both incredibly powerful and dangerously vulnerable.

What They Do

/etc/passwd: Stores user account info, including usernames and home directories.
/etc/shadow: Stores hashed passwords and password policies.

Why Linux Created Them

User authentication is the cornerstone of system security. These files provide a centralized way to manage users and their credentials.

The Jaw-Dropping Insight

Run this command:

cat /etc/passwd

You’ll see something like:

root:x:0:0:root:/root:/bin/bash
user:x:1000:1000:User:/home/user:/bin/bash

The x in the second column means the password is stored in /etc/shadow. But here’s the scary part: if /etc/shadow is compromised, an attacker can brute-force your hashed passwords offline.

Why This Matters for Security

Permissions on these files are everything. Make sure only root can access /etc/shadow, and audit them regularly for unauthorized changes.

Inside `/boot`: The Keys to the Kingdom

The /boot directory is where your system’s heart lies. It contains the kernel and bootloader configs—mess with this, and you can bring the entire system to its knees.

What It Does

This is where your system stores critical files for booting, like the kernel (vmlinuz) and GRUB configs.

Why Linux Created It

Without a dedicated boot directory, your system wouldn’t know how to start. It’s the first thing the computer looks at when powering on.

The Jaw-Dropping Insight

Run this command:

ls /boot

You’ll see files like:

vmlinuz-5.15.0-67-generic
initrd.img-5.15.0-67-generic
grub/

Modify GRUB configs, and you can change boot parameters, disable security features, or even redirect the system to boot into a malicious kernel.

Why This Matters for Security

Lock down /boot permissions. Better yet, encrypt your boot partition. If an attacker gets access here, it’s game over.

The Puppet Master: `/etc/systemd/system`

Systemd runs the show on modern Linux systems, and its configuration files are the puppet strings. If you’ve ever wondered how your server magically starts services on boot, this is where it happens.

What It Does

This directory contains unit files that define how services are started, stopped, and managed. It’s the brain of your server’s automation.

Why Linux Created It

Systemd replaced older init systems to provide a unified way to manage services. It’s powerful, but with great power comes great responsibility.

The Jaw-Dropping Insight

Run this command to list all active services:

systemctl list-units --type=service

Now check the contents of a suspicious unit file:

cat /etc/systemd/system/my-service.service

You might find something like:

[Service]
ExecStart=/usr/bin/my-app --config /etc/my-app.conf

If an attacker modifies this file, they can inject malicious commands that execute on every boot.

Why This Matters for Security

Audit your unit files regularly, and use systemctl status to monitor for unexpected changes. A compromised service file is a stealthy way to persist malware.

Conclusion: The Hunt Never Ends

I’ve barely scratched the surface here. Linux is a beautiful, terrifying beast, and every file in its ecosystem has a story—a purpose, a secret, a vulnerability. If you’re a sysadmin, developer, or security nerd, you owe it to yourself to dive deeper.

Hardening a Linux server isn’t just about running commands—it’s about understanding the system as a living, breathing organism. Every file, every process, every packet tells a story. And if you’re not listening, someone else will—someone who doesn’t have your best interests in mind.

So what are you waiting for? Fire up your terminal, start hunting, and remember: the deeper you dig, the darker it gets. Stay paranoid, stay caffeinated, and stay safe.

Linux File System Hunting: What I Discovered Digging Under the Hood (Beyond the Basics)

Bhupesh Chandra Joshi — Mon, 20 Apr 2026 09:45:41 +0000

As a Linux enthusiast, I’ve always been fascinated by how this operating system is structured — it feels like peeling back the layers of a well-designed machine. So one day, I decided to step into the role of a “system investigator” and dive deep into the Linux file system on my Ubuntu 24.04 LTS machine. My goal? To understand how the OS actually works under the hood, beyond the basics we all know.

This wasn’t just a theoretical exercise. I spent hours poking around directories, opening files, and connecting dots between what I saw and what I’d learned over the years. What surprised me most was how every file and folder has a story — a purpose in the grand design of Linux. If you’re a developer, DevOps engineer, or just someone curious about the inner workings of your system, understanding these details can make you a much better problem solver.

In this post, I’ll share 8 meaningful discoveries I made during my exploration. These aren’t just random files or commands — they’re insights into how Linux operates, solves real-world problems, and keeps your system humming along. Let’s dive in!

1. The Mighty /etc Directory: Linux’s Brain

What it does:

The /etc directory is home to configuration files that control almost every aspect of your system — from user accounts to network settings to services. It’s like Linux’s brain, where all the critical decisions are stored.

Why it exists:

Linux is designed to be modular and customizable. Instead of hardcoding settings into the kernel, /etc allows admins to tweak configurations without touching the core system. This makes Linux flexible and adaptable for different environments.

Real-world problem it solves:

Imagine you’re setting up a server with custom DNS or user permissions. Instead of rebuilding the system, you can modify files in /etc to tailor the OS to your needs. For example, /etc/ssh/sshd_config lets you tweak SSH settings to harden your server against attacks.

Interesting insight:

I opened /etc/environment and realized it’s where global environment variables are set. This means every user and process inherits these variables, making it a powerful tool for system-wide configuration. It’s a reminder that even simple files can have a huge impact.

2. DNS Configuration: The Gatekeeper of Networking

What it does:

Files like /etc/resolv.conf and /etc/hosts, along with systemd-resolved, manage how your system resolves domain names into IP addresses.

Why it exists:

Without DNS, you’d be stuck typing IP addresses into your browser — not very practical! These files ensure your system knows where to look when resolving names like google.com.

Real-world problem it solves:

When I was troubleshooting a network issue, I discovered that a misconfigured /etc/resolv.conf can break internet access. It’s also where you can manually set DNS servers (like Google’s 8.8.8.8) to bypass ISP restrictions.

Interesting insight:

I learned that /etc/hosts can be used for quick fixes — like redirecting specific domains to localhost for testing. But what really surprised me was systemd-resolved’s role in caching DNS queries, speeding up repeated lookups.

3. Routing Table: The Map of Network Traffic

What it does:

The routing table, accessible via /proc/net/route or commands like ip route, shows how packets are routed through your network interfaces.

Why it exists:

Routing is essential for communication. Without it, your system wouldn’t know whether to send packets to your Wi-Fi, Ethernet, or a specific gateway.

Real-world problem it solves:

When debugging connectivity issues, I found that checking the routing table can explain why packets aren’t reaching their destination. For example, a missing default gateway can prevent internet access entirely.

Interesting insight:

I was surprised to see how dynamic the routing table is. When I connected to a VPN, the table instantly updated to route traffic through the VPN’s gateway. It’s like watching your system adapt in real time.

4. System Logs: The Black Box of Linux

What it does:

System logs, stored in /var/log and accessible via tools like journalctl, record everything happening in your system — from kernel messages to app errors.

Why it exists:

Logs are the first place to look when something goes wrong. They’re like a black box for your system, capturing events that help you troubleshoot issues.

Real-world problem it solves:

When my system froze during boot, I used journalctl to find errors related to a misconfigured service. Without logs, I’d have been flying blind.

Interesting insight:

I discovered that /var/log/syslog is like a diary for your system’s core operations, while /var/log/auth.log is a goldmine for tracking login attempts. It’s a reminder of how much data your system quietly collects.

5. User Management Files: The DNA of Accounts

What it does:

Files like /etc/passwd, /etc/shadow, and /etc/group store information about users, passwords, and groups.

Why it exists:

Linux is a multi-user system, so it needs a way to manage who can access what. These files provide a centralized way to define users and their permissions.

Real-world problem it solves:

When I accidentally locked myself out of my system, I learned that /etc/shadow stores hashed passwords. With root access, I was able to reset my password and regain control.

Interesting insight:

I was surprised by how readable /etc/passwd is. It’s a simple text file that lists users and their home directories. But the real security lies in /etc/shadow, where passwords are encrypted. It’s a clever separation of concerns.

6. The /proc Filesystem: A Live Kernel X-Ray

What it does:

The /proc directory contains virtual files that provide a live view into the kernel’s inner workings — like CPU info, memory usage, and process details.

Why it exists:

Linux is built on transparency. Instead of hiding the kernel’s state, /proc lets you peek inside and see what’s happening in real time.

Real-world problem it solves:

When my CPU usage spiked unexpectedly, I opened /proc/cpuinfo to check my processor’s specs and /proc/meminfo to see if I was running out of RAM. It’s like having a diagnostic tool built into the filesystem.

Interesting insight:

I found /proc/<pid> directories fascinating. Each running process has its own folder, showing everything from memory maps to open file descriptors. It’s a reminder of how deeply Linux integrates processes into its design.

7. Device Handling in /dev: Where Hardware Meets Software

What it does:

The /dev directory contains special files that represent hardware devices, like disks, terminals, and even random number generators.

Why it exists:

Linux treats devices as files, making it easy to interact with hardware using standard tools. For example, /dev/null acts as a data sink, while /dev/random provides entropy for cryptographic operations.

Real-world problem it solves:

When I needed to wipe sensitive data, I used /dev/null to overwrite files. It’s also where you’ll find disk partitions, like /dev/sda1, when setting up storage.

Interesting insight:

I discovered that /dev/random can block if there’s not enough entropy, while /dev/urandom doesn’t. This trade-off between security and speed is a fascinating design choice.

8. Boot Configs in /boot: The Startup Playbook

What it does:

The /boot directory contains the files needed to boot your system, including the kernel and GRUB configurations.

Why it exists:

The boot process is complex, involving multiple stages. /boot ensures all the necessary components are available to get your system up and running.

Real-world problem it solves:

When my system failed to boot, I found the issue in /boot/grub/grub.cfg. A typo in the configuration file was preventing GRUB from loading the kernel. Fixing it brought my system back to life.

Interesting insight:

I learned that /boot/vmlinuz is the compressed kernel image. It’s fascinating how this tiny file contains the core of the operating system. It’s a reminder of Linux’s efficiency.

Conclusion: The Living Blueprint of Linux

Exploring the Linux file system felt like uncovering a treasure map. Each directory and file isn’t just storage — it’s a living blueprint of how the OS operates. From DNS settings to kernel diagnostics to boot configurations, every piece works together to create a seamless experience.

What surprised me most was how interconnected everything is. For example, a misconfigured file in /etc can ripple through the system, breaking services or even preventing boot. This kind of “hunting” makes you a better developer or sysadmin because it teaches you to think like the OS — to understand how the parts fit together.

One curious discovery I’m still exploring is the difference between /dev/random and /dev/urandom. Why does Linux offer two options, and how do they impact cryptographic security? If you’ve got insights, I’d love to hear them.

So here’s my challenge to you: fire up your Linux machine, pick a directory, and start hunting. You’ll be amazed at what you discover. And when you do, share your findings — I’d love to hear your stories!

Forem: Bhupesh Chandra Joshi

URL Parameters vs Query Strings in Express.js: A Practical Guide

Introduction

1. What are URL Parameters (Route Params)?

2. What are Query Strings (Query Parameters)?

3. Key Differences: Params vs Query

4. Accessing URL Parameters in Express.js

5. Accessing Query Strings in Express.js

6. When to Use Params vs Query Strings

Practical Tips & Best Practices

Useful npm Packages

Conclusion

Storing Uploaded Files and Serving Them in Express

1. Where Do Uploaded Files Actually Get Stored?

2. Local Storage vs External Storage (Mental Model)

3. Setting Up Folder-Based Storage Structure

4. Serving Static Files in Express (The Magic)

5. Complete Upload Example with Multer (pnpm style)

6. Accessing Uploaded Files via URL

7. Security Considerations (Don't Skip This!)

Bonus: Production-Ready Abstraction

Summary (The Takeaway)

Sessions vs JWT vs Cookies: Understanding Authentication Approaches

The Eternal Question Every Dev Asks at 2 AM

1. Cookies: The clingy ex who remembers everything

2. Sessions: The loyal butler who knows your entire life story

3. JWT (JSON Web Tokens): The stateless daredevil

Stateful vs Stateless – The Philosophical Battle

Sessions vs JWT – The Ultimate Showdown

Cookies in All This Drama

Libraries That Make Life Stupidly Easy (pnpm edition)

Quick Decision Cheat Sheet

Final Wisdom From Two Sleep-Deprived Devs

Async Code in Node.js: Callbacks and Promises

1. Why Async Code Exists in Node.js

2. Callback-based Async Execution

Synchronous Version (Blocking – Don’t do this in production)

Asynchronous Version with Callbacks

3. Problems with Nested Callbacks (“Callback Hell”)

4. Promise-based Async Handling

Converting the Example to Promises

5. Benefits of Promises

Visualizing the Concepts

Final Tips for Modern Node.js Development

How React Virtual DOM works under the Hood

Imagine You're Running a Super Busy Restaurant 🍽️

More Memorable Real-Life Examples 🧠

The Magic Trick: Diffing + Reconciliation ✨

React Native CLI Installation Guide: Step-by-Step for (Windows, macOS & Linux)

Introduction

Prerequisites

1. Install Node.js and npm

Using Official Installer (Easiest)

Verify Installation

2. Install Watchman (macOS & Linux only)

3. Install React Native CLI

4. Platform-Specific Setup

For Android (All Operating Systems)

For iOS (macOS only)

5. Create Your First React Native App

6. Run the App

Common Issues & Troubleshooting (2026)

Bonus: Recommended Development Setup (2026)

Conclusion

Tags for Hashnode:

Beyond the Cover: Demystifying JavaScript's this Keyword

1. What this Represents

2. this in the Global Context

3. this Inside Objects (The "Method" Context)

4. this Inside Regular Functions

5. How Calling Context Changes Everything

Common Scenarios:

Summary Table

Mastering Map and Set in JavaScript: Beyond Objects and Arrays

🛑 The Problem with Traditional Objects and Arrays

The Limitations of Object

The Limitations of Array

🗺️ What is a Map?

Map Key-Value Storage Visual

Map in Action

1. What `this` Represents

2. `this` in the Global Context

3. `this` Inside Objects (The "Method" Context)

4. `this` Inside Regular Functions

The Limitations of `Object`

The Limitations of `Array`

🗺️ What is a `Map`?

🛡️ What is a `Set`?

When to use `Map`

When to use `Set`

The Hidden Power of `/etc/resolv.conf`: DNS Poisoning Is Easier Than You Think

The Secret Life of `/proc/<pid>/environ`: Spying on Process Secrets

Routing Table Secrets: The Ghosts of `/proc/net/route`

The Underrated Danger of `/etc/passwd` and `/etc/shadow`

Inside `/boot`: The Keys to the Kingdom

The Puppet Master: `/etc/systemd/system`