1. Verbs over Nouns

Have you ever opened a file and seen a function simply named Product()? As a reader, I have no idea what this does. Is it creating a product in the database? Is it fetching it? Updating it? Functions do things. So, their names should always start with a verb. fetchProduct() or createProduct().

2. The Parameter Position Trap

We’ve all written a function signature that looks like this: createProduct(title, description, price, quantity, category, image), When you have more than three parameters, you are playing a dangerous game with the person calling the function. They have to remember the exact order. If someone accidentally swaps the category and image arguments, the compiler might not catch it, and your database will silently save corrupted data.

A solutions to this can be - limit parameters to 2 or 3. If you need more, wrap them in an object.

createProduct({ title, description, price, quantity, category, image });

3. Fail Fast, Return Early

When writing validation logic, our default instinct is to nest if-else blocks.

if (user.age >= 18) {
   if (!userExists) {
       
   }
}

becomes incredibly hard to figure out which closing bracket } belongs to which condition. To fix this we can just Invert our conditions and return as early as possible.

if (user.age < 18) return;
if (userExists) return;

4. Kill the Raw Boolean Flags

Imagine reviewing a pull request and seeing this line of code: registerUser(userData, true) What does true mean here? You have to stop reading, go find the registerUser function definition, read it, and come back. It completely breaks your reading flow.

const SHOULD_RETURN_TOKEN = true;
registerUser(userData, SHOULD_RETURN_TOKEN);

With that one small change, the code documents itself.

5. Keep a Single Level of Abstraction

This is a classic issue in Express.js or Next.js controllers. You open an API route, and inside one massive function, the code parses the HTTP request, validates the email, hashes the password, writes to the SQL database, and sends an HTTP 200 response.

A function should only do one thing. Don't mix high-level logic (HTTP responses) with low-level logic (database queries).

• Extract validation into a validateUser() function.

• Extract database logic into a UserService.createUser() function.

Your main controller shouldn't do the heavy lifting; it should just act like a traffic cop orchestrating these smaller, predictable functions.

What Exactly is an Object?

The easiest way to think about an object is like a dictionary or the contacts app on your phone.

In a dictionary, you look up a word (the key), and it gives you the definition (the value). A JavaScript object is just a collection of these key value pairs. The key is the label, and the value is the data.

Creating an Object

const person = {
  name: "Raj",
  age: 28,
  city: "Jaipur"
};

How to Access the Data

Once your data is inside an object, you need to know how to get it out. I learned there are two ways to do this.

1. Dot Notation

console.log(person.name); 
console.log(person.city);

2. Bracket Notation

console.log(person["name"]); 

const whatIWantToKnow = "age";

console.log(person.whatIWantToKnow); // Output: undefined

console.log(person[whatIWantToKnow]); // Output: 28

Changing the Data

Modifying an object is pretty straightforward.

1. **Updating a Property -**Just grab the property and give it a new value.

person.age = 29; 

1. Adding a Property - You don't need to change the original object. Just pretend the new key already exists and assign something to it.

person.job = "Developer";

1. Deleting a Property - If you need to completely remove something, use the delete keyword.

delete person.city;

Looping Through an Object

what if you want to print out everything inside the object? Because objects don't have numbered indexes like arrays do, a normal for loop doesn't work.

const person = {
  name: "Raj",
  age: 28,
  city: "Jaipur"
};

for (let key in person) {
  // Notice I have to use bracket notation here because 'key' is a variable!
  console.log(`\({key} : \){person[key]}`);
}

/* Console Output:
name: Raj
age: 28
city: Jaipur
*/

That’s it for the basics, switching my mindset from putting everything in an array to using an object to label my data has made my code so much easier to read.

The if statement is the simplest way to make a decision in code. It basically says, "Check if this condition is true. If it is, run the code inside the block."

let age = 20;

if (age >= 18) {
  console.log("Welcome in!");
}

1. It sees the variable age is set to 20.

2. It looks at the condition (age >= 18).

3. Because 20 is indeed greater than 18, the condition is "true".

4. Since it's true, it goes inside the curly braces {} and prints "Welcome in!".

2. The if-else Statement

The if statement is great, but what if the condition is false and you still want something to happen? That’s where else comes in. It acts as a backup plan.

let marks = 35;

if (marks >= 40) {
  console.log("You passed!");
} else {
  console.log("You failed. Better luck next time.");
}

How this runs:

1. The marks variable is 35.

2. The computer checks (marks >= 40).

3. Because it's false, it skips the first block of code completely.

4. It sees the else block and automatically runs it, printing "You failed. Better luck next time."

3. The else if

Sometimes a simple "yes or no" isn't enough. You might have multiple conditions to check. You can string these together using else if.

let score = 85;

if (score >= 90) {
  console.log("Grade: A");
} else if (score >= 80) {
  console.log("Grade: B");
} else if (score >= 70) {
  console.log("Grade: C");
} else {
  console.log("Grade: F");
}

4. The switch Statement

If you have a lot of specific values to check, writing a massive else if ladder gets really messy and hard to read.

let trafficLight = "yellow";

switch (trafficLight) {
  case "green":
    console.log("Go!");
    break;
  case "yellow":
    console.log("Slow down!");
    break;
  case "red":
    console.log("Stop!");
    break;
  default:
    console.log("Invalid light color.");
}

Why do we need break?

I feel this is the biggest trap for beginners. If the computer finds a match, it will run that code. But if you don't include the word break, the code will "fall through" and automatically run the "red" and "default" console logs too, even though they don't match!

When to use which?

• Use if-else when - You are checking for ranges (like age > 18) or comparing different variables. It's your most flexible, everyday tool.

• Use switch when - You have one specific variable and you are checking it against a bunch of exact, fixed values. It keeps your code much easier to read.

In production, logs are not text files for humans to read. They are structured telemetry data meant to be indexed, searched, and aggregated by machines. I was re-exploring Winston today, and I want to break down how to actually set this up for a real-world Node.js environment.

The Architecture of Winston

Winston has survived this long in the Node ecosystem because it fundamentally gets the abstraction right. It separates what you are logging from where it is going. It does this using three concepts:

1. Levels - The severity of the log (e.g., error, info, debug).

2. Formats - The shape of the log (e.g., raw text vs. structured JSON).

3. Transports - The destination of the log (e.g., the console, a file, or an external API).

By decoupling these, you can say, "Send all info logs to the console as text, but send all error logs to an external service as JSON."

1. Setting Up the Baseline

First, install the package: npm install winston.

When setting up your logger, the non-negotiable rule for production is JSON formatting. If your logs are JSON.

const winston = require('winston');
const { combine, timestamp, json, errors } = winston.format;

const logger = winston.createLogger({
  level: 'info', 
  format: combine(
    errors({ stack: true }), 
    timestamp(),             
    json()                   
  ),
 
  defaultMeta: { service: 'payment-service', env: process.env.NODE_ENV }, 
  transports: [
    
    new winston.transports.Console() 
  ]
});

By default, if you pass a JS Error object to a logger, it often just prints the message ("Database connection failed"). In an outage, you need the stack trace to find the exact file and line number. This format rule ensures the stack trace is preserved in the JSON output.

2. The Real Power: Context via Child Loggers

A log that says logger.info("Fetching user cart") is useless if you have 1,000 requests per second. Which user? Which request?

You need context. But passing userId and requestId to every single logger.info() call throughout your codebase is messy and prone to errors. Instead, you use Child Loggers.

app.use((req, res, next) => {
  req.logger = logger.child({
    requestId: req.headers['x-request-id'] || generateId(),
    userId: req.user?.id || 'anonymous'
  });
  
  next();
});


function processPayment(req) {
  req.logger.info("Starting payment processing"); 
  
}

3. Quick Profiling

If you don't have a heavy Application Performance Monitoring (APM) tool set up yet, you can measure how long bottlenecks take directly through your logs.

const profiler = req.logger.startTimer();


await database.query('...');

profiler.done({ message: 'Database query executed', queryName: 'fetch_user_cart' });

Because your logs are in JSON, this outputs a key like "durationMs": 342. You can then go to your logging platform and write a query like durationMs > 500 to instantly find all slow database queries.

4. Shipping Logs Off-Server

If your application is running in a container, the local filesystem is ephemeral. If the app crashes and the container restarts, any .log files stored locally are permanently deleted—along with the exact error logs you need to figure out why it crashed.

const { Logtail } = require("@logtail/node");
const { LogtailTransport } = require("@logtail/winston");

const logtail = new Logtail(process.env.LOGTAIL_TOKEN);

logger.add(new LogtailTransport(logtail));

The logger just starts quietly streaming the data over the network in the background.

Historically, solving this meant writing massive, ugly manual validation blocks full of if statements to check typeof for every single field. This clutters your business logic and This is where Zod comes in.

Zod: Your Single Source of Truth

Zod is a TypeScript-first schema declaration and validation library. It acts as the missing bridge between your runtime data and your compile time types. Instead of writing a TypeScript interface and a separate validation function, you define a Zod schema once.

import { z } from 'zod';


const userSchema = z.object({
  name: z.string().min(2, "Name is too short").max(50),
  email: z.string().email("Invalid email"),
  age: z.number().int().positive(),
  preferences: z.object({
    theme: z.enum(["light", "dark"]).default("light")
  }).optional()
});


type UserPayload = z.infer<typeof userSchema>;

Implementing Zod in Express

When raw JSON hits your Express server, you need to pass it through this schema. Zod gives you two primary ways to do this:

1. .parse(data): Checks the data and throws an exception if it’s invalid.

2. .safeParse(data): Checks the data and returns an object telling you if it worked or failed, without throwing errors.

Here is the pattern I highly recommend, a simple, reusable Express middleware that validates the body before it ever reaches your route handler -

import { Request, Response, NextFunction } from 'express';
import { AnyZodObject } from 'zod';

const validateBody = (schema: AnyZodObject) => {
  return (req: Request, res: Response, next: NextFunction) => {
    const result = schema.safeParse(req.body);
    
    if (!result.success) {
      
      return res.status(400).json({
        error: "Validation failed",
        details: result.error.errors.map(err => ({
          field: err.path.join('.'),
          message: err.message
        }))
      });
    }

    
    req.body = result.data;
    next();
  };
};

Now, the actual route handler becomes incredibly clean.

app.post('/users', validateBody(userSchema), (req, res) => {
  
  const userData = req.body; 
  res.status(201).json({ success: true });
});

Why Do We Need Arrays?

Imagine you are building a simple app to track your top three favorite fruits. Without arrays, you would have to store each fruit in its own separate variable.

let fruit1 = "Apple";
let fruit2 = "Banana";
let fruit3 = "Mango";

// with array
let fruitArray = ["apple", "banana", "mango"]

How to Create an Array

Creating an array in JavaScript is incredibly straightforward. You use square brackets [] and separate your items with commas.

//  array of strings
let tasks = ["Wake up", "Drink water", "Learn JavaScript"];

// array of numbers
let testScores = [85, 92, 78, 99];

Accessing Elements Using the Index

How do you get a specific item out of your array? You use its index. The most important rule to remember about arrays is that counting starts at 0, not 1. This is known as zero-based indexing.

If we look at our fruits array:

• "Apple" is at index 0

• "Banana" is at index 1

• "Mango" is at index 2

let fruits = ["Apple", "Banana", "Mango"];

console.log(fruits[0]); 
console.log(fruits[2]); 

Updating Elements

Arrays are flexible. You can easily change the value of an element after the array has been created by selecting its index and assigning a new value. Let's say we want to replace "Banana" with "Orange"

let fruits = ["Apple", "Banana", "Mango"];


fruits[1] = "Orange";

console.log(fruits); 

Basic Looping Over Arrays

If you want to print every item in your array, we can use a basic for loop to loop over the array.

let fruits = ["Apple", "Orange", "Mango"];

for (let i = 0; i < fruits.length; i++) {
  console.log("I love eating " + fruits[i]);
}

/* Output:
I love eating Apple
I love eating Orange
I love eating Mango
*/

Lets dry run it once -

1. let i = 0: We start our counter (i) at 0, which perfectly matches our array's first index.

2. i < fruits.length: The loop keeps running as long as i is less than the total number of items (3).

3. i++: After each loop, i increases by 1, allowing us to move to the next item in the array.

const service = {
  name: "Payment Gateway",
  start: function() {
    console.log(`Starting ${this.name}`);
  }
};

service.start(); 

Look at service.start(). Who is on the left of the dot? service. So, this = service.

const startService = service.start;
startService(); 

Look at startService(). There is nothing to the left of the dot. It’s just a raw function call. The context is lost, this defaults to undefined, and your app crashes. To fix this, JavaScript gives us three methods on the Function.prototype to manually force the this context call, apply, and bind.

1. CALL

call immediately fires the function, forcing this to be the first argument you pass. Any remaining arguments are passed individually.

function logError(level, message) {
  console.log(`[\({this.service}] \){level}: ${message}`);
}

const context = { service: "Auth" };
logError.call(context, "CRITICAL", "connection lost"); 

2. APPLY

apply is exactly the same as call, but it takes the function's arguments as a single array.

logError.apply(context, ["CRITICAL", "connection lost"]);

3. BIND

bind doesn't execute the function immediately. Instead, it returns a new function with this permanently locked to the object you provided. This is how you fix the callback problem.

const safeStart = service.start.bind(service);

setTimeout(safeStart, 1000); 

writing the polyfills

To truly understand a system, you build it yourself. If we were to write these methods from scratch, how would the engine actually do it?

The call Polyfill

trick is simple, temporarily attach the function to the target object as a property. Then call it. By doing this, the object is literally to the left of the dot.

Function.prototype.myCall = function(context = globalThis, ...args) {
  
  const fnKey = Symbol('fn');
  
  
  context[fnKey] = this;
  
  const result = context[fnKey](...args);
 
  delete context[fnKey];
  return result;
};

The apply Polyfill

Almost identical to call, but we spread an array.

Function.prototype.myApply = function(context = globalThis, argsArray = []) {
  const fnKey = Symbol('fn');
  context[fnKey] = this;
  
  const result = context[fnKey](...argsArray);
  
  delete context[fnKey];
  return result;
};

The bind Polyfill

bind needs to return a closure. When that closure is eventually called, it uses apply internally to execute the original function with the locked context.

Function.prototype.myBind = function(context = globalThis, ...boundArgs) {
  const originalFn = this;
  
  return function(...executionArgs) {
    return originalFn.apply(context, [...boundArgs, ...executionArgs]);
  };
};

Mastering execution context moves you from randomly guessing why a callback broke, to deliberately architecting how your data flows through asynchronous boundaries.

If you’ve done any backend work, you know what happens when an API receives a JSON payload. It comes over the wire as a raw string. You can’t easily loop through a string to find a specific user ID. You convert that string into a native object loaded into the server's memory. The DOM is the exact same concept, just for the browser. The browser downloads your raw HTML string, parses it, and creates a massive, living data structure in its memory.

Why a Tree?

HTML is inherently nested. An <html> tag contains a <body>, which contains a <div>, which contains a <p>. The browser models this exact hierarchy using a Tree data structure. Every single HTML tag becomes a "node" in this tree. This tree is the DOM. It is a representation of your document, built out of objects, modelled as a tree.

The DOM is actually a Web API provided by the browser. In Chrome, the DOM is implemented in C++ under the hood. Browser give you a global object called document. If you call methods on document, Browser lets you read or update the C++ tree.

const button = document.querySelector('.submit-btn');
button.style.backgroundColor = 'red';

You are writing JavaScript, but you are interacting with the browser's DOM API to change the state of a node in its memory tree.

Why is the DOM slow?

If you've been around frontend tooling for a while, you've probably heard the phrase, "The DOM is slow. That's why we need React and the Virtual DOM." That phrase is actually a half-truth. Updating a node in the DOM is incredibly fast. Remember, it's just updating an object in memory. If you change a button's color in the DOM, that memory update takes less than a fraction of a millisecond.

The DOM isn't slow. Rendering is slow.

When you change something in the DOM tree, the browser engine realizes the tree has mutated. It now has to figure out what that change means for the pixels on the screen.

1. It has to recalculate the CSS.

2. It has to figure out the geometry of the page changing this text make the button wider? Did that push the image below it down? (This is called a Reflow or Layout).

3. Finally, it has to physically draw the new pixels on the screen (This is called a Repaint.

Reflows and repaints are mathematically expensive. If you have a list of 1,000 items and you write a JavaScript for loop that updates them one by one, you trigger that expensive render pipeline 1,000 times in a row. The browser will freeze.

ools like React introduced the Virtual DOM to solve this. They do all the heavy calculations in a lightweight JavaScript copy of the tree, figure out the absolute bare minimum number of changes needed, and then update the real DOM in one big batch. They optimize the writes to avoid triggering the browser's slow render pipeline too many times.

Wrapping up

Whenever you are building for the web, keep the system architecture in your head -

• HTML: The raw string payload sent over the wire.

• The DOM: The tree of objects the browser builds in memory from that string.

• JavaScript: The language we use to tell the browser how to update that tree.

The Problem: The Coupling Trap

we first need to understand the problem. Let's use a classic e-commerce application as an example. Imagine a user places an order. The request hits our Express controller, which then calls an OrderService to handle the business logic. Inside the createOrder method, we don't just save the order to the database. We usually have a laundry list of side effects:

1. Send an order confirmation email to the user.

2. Update the inventory stock.

In a naive approach, our OrderService would import an EmailService and an InventoryService, calling their methods directly . Why is this bad? This introduces tight coupling . The OrderService is now fully dependent on the email and inventory modules. If the email service throws an error, it might crash the entire order creation process. This makes the code harder to maintain.

The Solution - Event-Driven Architecture

We want to decouple these services. The OrderService shouldn't care how an email is sent or how the inventory is updated. It should only care about creating the order. Think of Event-Driven Architecture like a public announcement system. Instead of the OrderService directly telling the EmailService what to do, it simply grabs a megaphone and shouts to the rest of the application - Hey everyone, an Order was just Created.

Implementing EDA in Node.js

Most of Node.js's core API are already built around an asynchronous, event-driven architecture. For our custom business logic, Node gives us a powerful tool, the EventEmitter class from the events module.

Step 1: Extend the EventEmitter

First, we make our OrderService a child of the EventEmitter class. By using the extends keyword, our service inherits the superpower to broadcast events.

import { EventEmitter } from 'events';

export class OrderService extends EventEmitter {
    createOrder(orderData) {
        // 1. Logic to save order to the database goes here
        const newOrder = { id: Date.now().toString(), ...orderData };

        // 2. Broadcast the event!
        this.emit('order:created', newOrder); 

        return newOrder;
    }
}

Step 2: Emitting the Event

Notice the this.emit('order:created', newOrder) line above. We give the event a descriptive name (order:created) and pass along the relevant data payload (newOrder). Our service's job is now done.

Step 3: Registering the Subscribers

Now, we need to wire up the listeners that will react to this event. We do this by calling the .on() method on the instance of our OrderService.

const orderService = new OrderService();
const emailService = new EmailService();
const inventoryService = new InventoryService();


orderService.on('order:created', (data) => {
    emailService.sendEmail(data);
});

orderService.on('order:created', (data) => {
    inventoryService.updateInventory(data);
});

A Crucial Gotcha

Here is a massive misconception that trips up a lot of developers, they often assume the EventEmitter acts like an asynchronous message queue. It does not. When you call this.emit(), Node.js will execute all the registered listeners synchronously in the exact order they were registered . If you place a console.log('After emit') right beneath your emit function, it will only log after the email and inventory callbacks have finished running . If you want these listeners to not block the main execution thread, you need to handle them asynchronously, using async/await inside the callback or wrapping the logic in setImmediate.

Event-Driven Architecture is a phenomenal pattern for separating concerns and keeping your backend codebase modular. By utilizing Node's built-in EventEmitter.

HAPPY CODING.

The Problem: The "Mailman" Model (HTTP)

To get why WebSockets are cool, you have to understand why standard websites are kind of annoying for real-time stuff. Think of standard HTTP like sending a letter via mail -

1. You - Send a letter asking "Do I have new messages?" (Request)

2. Server - Reads letter, checks database, writes back "No." (Response)

3. End of conversation.

If you want to check again 5 seconds later, you have to send a whole new letter. Basically http is stateless.

we used to solve this by making the browser ask the server every single second: "Any updates? Any updates? Any updates?" This is called Polling. It works, but it’s exhausting for your server and eats up your user’s data.

The Solution: The "Phone Call" (WebSockets)

WebSockets change the rules. Instead of mailing letters back and forth, you open a phone line.

1. You - Dial the server.

2. Server - Picks up.

3. The line stays open.

Now, nobody has to ask for updates. If the server has a message for you, it just speaks. If you have a message, you just speak. It’s a two way, persistent connection.

Let’s Build Something

Enough talk. Let's write some code. We’ll use Node.js for this.

If you want to follow along, create a folder, open your terminal, and run -

npm init -y. npm install express socket.io

1. The Backend (index.js)

Standard Express apps look one way, but when you add Socket.IO, you have to do a little "wrapping" of the server.

const express = require('express');
const http = require('http'); 
const { Server } = require("socket.io");

const app = express();

const server = http.createServer(app);
const io = new Server(server);

app.get('/', (req, res) => {
  res.sendFile(__dirname + '/index.html');
});

io.on('connection', (socket) => {
  console.log('A user connected! Socket ID:', socket.id);


  socket.on('chat message', (msg) => {

    io.emit('chat message', msg);
  });
});

server.listen(3000, () => {
  console.log('Server running on port 3000');
});

The important bits:

• io.on('connection'): This runs every single time a new tab opens your site.

• socket.id: Every user gets a random, unique ID. This is how you tell users apart.

• io.emit: This shouts the message to everyone. If you used socket.emit, you'd only be whispering back to the person who sent the message.

2. The Frontend (index.html)

This is the HTML file the server will send to the browser.

<!DOCTYPE html>
<html>
  <body>
    <h1>Simple Chat</h1>
    <input id="input" autocomplete="off" /><button onclick="sendMsg()">Send</button>
    <ul id="messages"></ul>

    <script src="/socket.io/socket.io.js"></script>
    <script>

      const socket = io();

      function sendMsg() {
        const input = document.getElementById('input');
        if (input.value) {

          socket.emit('chat message', input.value);
          input.value = '';
        }
      }


      socket.on('chat message', function(msg) {
        const item = document.createElement('li');
        item.textContent = msg;
        document.getElementById('messages').appendChild(item);
      });
    </script>
  </body>
</html>

Is this the only way?

Short answer, NO. You don't always need WebSockets. WebSockets are heavy. They keep a connection open 24/7. Sometimes, that's overkill.

If you want to make your app feel realtime, we have 4 popular ways

1. Short polling

2. Long polling

3. SSE (server side events)

4. Web sockets

WebSockets feel like magic, but they are just a persistent phone call between your browser and the server. Socket.io just makes sure the call doesn't drop.

How you actually code it

It’s surprisingly simple. You just need two files.

The Bottleneck

Lets understand this with a very simple and realistic example.

• Take a folder of high-res nature photos.

• Resize them, blur them, and grayscale them.

• Set a timer on it

I already did it on my machine and here are the results. Running this on the main thread took over 11 seconds for just 10 images. For those 11 seconds, the app was dead. WHEN I tried to ping the homepage, it timed out. In the real world, that’s unacceptable.

Now, lets see the worker way.

1. The Manager

// index.js
const { Worker } = require('worker_threads');

function processImageInBackground(filePath) {
  return new Promise((resolve, reject) => {

    const worker = new Worker('./image-worker.js', {
      workerData: { filePath } 
    });

    worker.on('message', (result) => {
      console.log(`Worker said: ${result}`);
      resolve(result);
    });

    worker.on('error', reject);
  });
}

processImageInBackground('./huge-photo.jpg');

2. The Worker

// image-worker.js
const { parentPort, workerData } = require('worker_threads');
const jimp = require('jimp'); 


const { filePath } = workerData;


async function run() {
  const image = await jimp.read(filePath);
  await image.resize(100, 100).writeAsync(`processed/output.jpg`);

  parentPort.postMessage('Done processing!');
}

run();

The "Whoa" Moment 🤯

I took that same 11-second task and refactored it to use Worker Threads. spun up a worker for each image so they all processed at the exact same time.

The result? just took 4 seconds.

That is a nearly 3x speed improvement. But more importantly, the main thread wasn't blocked. The server stayed responsive the entire time.

TL;DR

If you’re doing heavy CPU work in Node.js, stop blocking the event loop.

1. Use worker_threads.

2. Offload the heavy math/image processing to a separate file.

3. Use a Pool to manage them so you don't fry your server.

The stack I’m opting for this one is Next.js. In this one I’m going to walk you through how I set this up in a production Next.js 15+ app. No fluff, just the code that actually works.

The Stack

I am keeping it simple here

• Next.js 15+ (App Router, obviously)

• Better Auth

• MongoDB (Because I don’t want to write SQL, ugh)

Phase 1: The Setup

pnpm add better-auth mongodb

The Environment Variables

You know the drill. Create a .env file. Do not skip the BETTER_AUTH_SECRET.

// .ENV
MONGODB_URI=mongodb+srv:
BETTER_AUTH_SECRET=
BETTER_AUTH_URL=


GOOGLE_CLIENT_ID=
GOOGLE_CLIENT_SECRET=

Phase 2: The Server-Side Config

Here is where Better Auth shines. We need to create a central Auth instance. I usually throw this in src/lib/auth.ts. The beauty here is the adapters. We don't need to manually write Mongoose schemas for users, sessions, or accounts. Better Auth handles the collections automatically.

import { betterAuth } from "better-auth";
import { mongodbAdapter } from "better-auth/adapters/mongodb";
import { MongoClient } from "mongodb";


const client = new MongoClient(process.env.MONGODB_URI!);
const db = client.db("my-production-app");

export const auth = betterAuth({
    database: mongodbAdapter(db),

    emailAndPassword: {
        enabled: true,
    },

    socialProviders: {
        google: {
            clientId: process.env.GOOGLE_CLIENT_ID!,
            clientSecret: process.env.GOOGLE_CLIENT_SECRET!,
        },
        github: {
            clientId: process.env.GITHUB_CLIENT_ID!,
            clientSecret: process.env.GITHUB_CLIENT_SECRET!,
        } 
    }
});

Phase 3: The API Route

In older libraries, this part used to be a mess of callbacks and switch statements. Now? It’s basically two lines of code. We need a catch-all route so Better Auth can handle /api/auth/sign-in, /sign-out, etc etc

import { auth } from "@/lib/auth"; 
import { toNextJsHandler } from "better-auth/next-js";

export const { GET, POST } = toNextJsHandler(auth);

Phase 4: The Client

Next.js creates a strict boundary between Server and Client, we need a dedicated Auth Client to use in our React components. This gives us hooks like useSession and functions like signIn.

import { createAuthClient } from "better-auth/react";

export const authClient = createAuthClient({
    baseURL: process.env.BETTER_AUTH_URL 
});

export const { signIn, signUp, signOut, useSession } = authClient;

Phase 5: Building a Login Form

Let's build a proper Sign-Up page. I’m going to use the signUp function we just exported. Note how we handle the callbackURL, this controls where the user lands after they register.

"use client";

import { useState } from "react";
import { signUp } from "@/lib/auth-client"; 
import { useRouter } from "next/navigation";

export default function SignUp() {
    const [email, setEmail] = useState("");
    const [password, setPassword] = useState("");
    const [name, setName] = useState("");
    const [loading, setLoading] = useState(false);
    const router = useRouter();

    const handleRegister = async () => {
        setLoading(true);
        await signUp.email({
            email,
            password,
            name,
            callbackURL: "/dashboard", 
        }, {
            onSuccess: () => {

                router.push("/dashboard");
            },
            onError: (ctx) => {
                alert(ctx.error.message); 
                setLoading(false);
            }
        });
    };

    return (
        <div className="flex flex-col gap-4 p-10 max-w-sm mx-auto">
            <h1 className="text-2xl font-bold">Join the App</h1>

            {/* Social Auth is literally one function call */}
            <button 
                onClick={() => signUp.social({ provider: "google", callbackURL: "/dashboard" })}
                className="bg-white border text-black p-2 rounded flex items-center justify-center gap-2"
            >
                Continue with Google
            </button>

            <div className="text-center text-gray-500">or</div>

            <input className="border p-2 rounded" placeholder="Name" onChange={(e) => setName(e.target.value)} />
            <input className="border p-2 rounded" placeholder="Email" onChange={(e) => setEmail(e.target.value)} />
            <input className="border p-2 rounded" type="password" placeholder="Password" onChange={(e) => setPassword(e.target.value)} />

            <button 
                onClick={handleRegister} 
                disabled={loading}
                className="bg-black text-white p-2 rounded hover:opacity-80 disabled:opacity-50"
            >
                {loading ? "Creating Account..." : "Sign Up"}
            </button>
        </div>
    );
}

Phase 6: Protecting Routes

We need to protect our routes. In 2026, the best way to do this in the App Router isn't just client-side checking, it's Server Side Checking in a Layout.

import { auth } from "@/lib/auth"; 
import { headers } from "next/headers"; 
import { redirect } from "next/navigation";

export default async function DashboardLayout({ children }: { children: React.ReactNode }) {

    const session = await auth.api.getSession({
        headers: await headers() 
    });
    if (!session) {
        redirect("/sign-in");
    }

    return (
        <div>
            <header className="p-4 border-b flex justify-between items-center">
                <h2 className="font-bold">Dashboard</h2>
                <div className="flex gap-4 items-center">
                    <p>Hello, {session.user.name}</p>
                    {/* Note: You'll need a Client Component for the Logout button */}
                </div>
            </header>
            <main className="p-4">
                {children}
            </main>
        </div>
    );
}

1. No Flash of Unauthenticated Content - Because we check in the layout (server-side), the user never sees the dashboard if they aren't allowed.

2. Type Safety - session.user.name is typed. I didn't have to create a custom interface, Better Auth inferred it from my schema.

3. Flexibility- If I want to add 2FA later? I just add twoFactor: { enabled: true } in the config. That's it.

It’s genuinely the cleanest auth setup I’ve touched in a long time. If you want a visual walkthrough, definitely check the Coder's Gyan video linked, it was a huge help when I was figuring this out.

The Problem: Why Does OAuth Even Exist?

Imagine you use a budgeting app called "BudgetBuddy." BudgetBuddy needs to see your bank transaction history to help you save money.

The Old (Bad) Way

In the early days of the internet, BudgetBuddy might have asked you for your bank username and password.

This is bad for a few reasons:

• Security: You just gave a third-party app the keys to your entire bank account.

• Trust: If BudgetBuddy gets hacked, your bank account gets hacked.

• Control: You can’t limit access. BudgetBuddy has full access to transfer money, change settings, etc., just like you do.

The OAuth Way

This is why "Login with Google" (and OAuth) exists.

OAuth solves the problem of Delegated Authorization. It’s like a valet key for your car. You give the valet a special key that only starts the ignition (so they can park it), but it doesn't open the glove box or the trunk.

With OAuth we get two benefits

1. No Password Sharing: You never give your password to the app. You give it to the Provider (like Google).

2. Token-Based: The app gets a "token" that allows access to specific data for a limited time.

The Flow: How It Actually Works

The specific version of OAuth we see most often is called the Authorization Code Flow. It’s a bit of a dance between four main characters.

The Step-by-Step Flow

Here is what happens when you click that login button:

1. The Ask: You click "Login." The Client redirects you to the Authorization Server (Google).

2. The Permission: Google asks you: "Do you want to let this app see your email?" You say Yes.

3. The Code: Google redirects you back to your app with a temporary Authorization Code in the URL.

4. The Exchange: Your app takes that code and whispers to Google (server-to-server): "Hey, I have this code from the user. Can I have a real Access Token now?"

5. The Token: Google verifies the code and gives your app an Access Token.

6. The Data: Your app uses that token to fetch your data from the API.

Minimal Implementation (Node.js + Express)

Let's build this! We will assume we are connecting to a provider (GitHub or Google).

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

// we usually get these from your provider's developer console
const CLIENT_ID = 'your_client_id';
const CLIENT_SECRET = 'your_client_secret';
const REDIRECT_URI = 'http://localhost:3000/auth/callback';


const AUTH_URL = 'https://provider.com/oauth/authorize';
const TOKEN_URL = 'https://provider.com/oauth/token';
const USER_INFO_URL = 'https://api.provider.com/user';

Step 1: The Redirect

app.get('/auth/login', (req, res) => {
    const params = new URLSearchParams({
        client_id: CLIENT_ID,
        redirect_uri: REDIRECT_URI,
        response_type: 'code',
        scope: 'read:user' 
    });

    res.redirect(`${AUTH_URL}?${params.toString()}`);
});

Lets breakdown it line by line

• URLSearchParams: This is a handy utility to build query strings safely.

• client_id: Identifies our app to the provider.

• redirect_uri: Tells the provider, "Once the user says yes, send them back here."

• response_type: 'code': This is crucial. It tells the provider we are using the Authorization Code Flow. We want a code, not a token (yet).

• res.redirect: We physically move the user's browser from our site to the provider's site.

Step 2: The Callback

The user has clicked "Allow." The provider sends them back to our REDIRECT_URI with a surprise attached to the URL - http://localhost:3000/auth/callback?code=abc12345.

app.get('/auth/callback', async (req, res) => {
    const { code } = req.query;

    if (!code) {
        return res.status(400).send('Authorization code missing.');
    }

    try {
        /
        const tokenResponse = await exchangeCodeForToken(code);

        const userData = await fetchUserProfile(tokenResponse.access_token);

        res.send(`Hello, ${userData.name}! You are logged in.`);
    } catch (error) {
        res.status(500).send('Authentication failed');
    }
});

• req.query - In Express, this is how we read the URL parameters. We extract the code.

• Error Handling - If there is no code, something went wrong (or the user said "No"), so we stop.

• The Async Flow - We pause to exchange the code for a token, then use the token to get user data.

Step 3: The Exchange

This is the most critical security step. We take the "temporary code" and swap it for the "permanent token." This happens on the server side, so the user never sees it.

async function exchangeCodeForToken(code) {
    const response = await axios.post(TOKEN_URL, {
        client_id: CLIENT_ID,
        client_secret: CLIENT_SECRET,
        code: code,
        redirect_uri: REDIRECT_URI,
        grant_type: 'authorization_code'
    }, {
        headers: { 'Accept': 'application/json' }
    });

    return response.data;
}

• axios.post: We are sending a POST request to the provider.

• client_secret: This is our app's password. We never share this on the frontend. This proves to the provider that we are the ones asking for the token, not a hacker.

• grant_type: 'authorization_code': This tells the provider, "I am exchanging an auth code for a token."

• response.data: If successful, this object contains the access_token (and often a refresh_token).

Step 4: Using the Token

async function fetchUserProfile(accessToken) {
    const response = await axios.get(USER_INFO_URL, {
        headers: {
            'Authorization': `Bearer ${accessToken}`
        }
    });

    return response.data;
}

• Authorization Header - This is the standard way to present a token.

• Bearer - Think of this like saying, "I am the bearer of this valid ticket."

• response.data - This will finally return the json data we wanted (e.g., { "name": "John Doe", "email": "john@example.com" }) . Typical john doe.

Should you use this code in production?

Probably not. Libraries handle edge cases, security vulnerabilities, and token rotation much better than a raw implementation. But now, when you’ll use libraries like NextAuth, better auth, you’re not just copy pasting code without understnding.

Ever wondered what's actually happening under the hood when you type app.get()? Express feels like magic because it is abstraction done right. It hides the messy parts of handling HTTP requests so we can focus on shipping.

Building a mini Express teaches what frameworks actually do. You'll understand routing, middleware chains, and why abstraction layers matter. Think of it this way a framework is just structured orchestration sitting on top of http.createServer.

2. Designing the Mini Framework API

const app = miniExpress();

app.get("/users", (req, res) => { res.send("Users"); });

app.listen(3000);

We're building an abstraction layer that feels like Express, our own mini express.

3. Routing System

The router is just a registry that matches incoming requests to handlers -

const routes = [];

app.get = (path, handler) => {
  routes.push({ method: "GET", path, handler });
};

// when the request comes in 

const match = routes.find(
  r => r.method === req.method && r.path === req.url
);

Simple O(n) lookup. Express uses fancy trie structures for speed. For learning purposes, a loop works fine. The concept match method and path, then execute is what matters.

4. Middleware System

This is where things get interesting. Middleware is just a function that runs before your route handler, with the power to continue or stop the chain.

const middlewares = [];

app.use = (fn) => {
  middlewares.push(fn);
};

//
//
//

let i = 0;

function next() {
  const middleware = middlewares[i++];
  if (middleware) {
    middleware(req, res, next);
  }
}

Each middleware calls next() to pass control to the next one. This creates a linear execution chain where any middleware can modify the request, send a response early, or pass it along. It's control flow inversion, instead of you calling functions, the framework calls you and asks "what next?"

5. Enhancing responses (res)

res.send = (data) => {
  res.setHeader("Content-Type", "application/json");
  res.end(JSON.stringify(data));
};

Frameworks enhance primitives. We can add anything in our mini express. i.e. res.json, res.status, whatever solves our purpose.

6. Order of Execution

app.use(authMiddleware);
app.get("/profile", handler);

The auth check runs first. If it fails, the profile handler never sees the request. Route matching typically happens after global middleware. That's a design decision Express made, and it affects how you structure apps. Order is architecture.

7. Handling 404 and Fallback

What happens when no route matches? Lets see what can we do here

if (!match) {
  res.statusCode = 404;
  res.end("Not Found");
}

Express has a default 404 handler, but in production we usually override it. Defining fallback behavior is part of framework design.

8. Handling Errors

if (err) {
  errorHandler(err, req, res);
}

Error middleware takes four arguments (err, req, res, next) and centralizes failure handling. Instead of try-catch blocks scattered everywhere, you bring all errors to one place.

9. Comparing to Real Express Internals

Oue mini express works, but real Express has more moving parts. It uses the connect middleware engine internally, with a Layer abstraction that wraps each middleware. The Router object handles nested routes and params.

10. Production Limitations of Your Mini Framework

Here are somethings that we did’nt really touch upon in this one, you try some of them on your own, it would be a fun ride

• No async error handling try-catch won't catch errors in async middleware

• No route params /users/:id won't work, just exact matches

• No body parsing req.body is undefined; you'd need to stream and parse

• No query parsing ?foo=bar stays a string

• No performance optimization that O(n) route lookup breaks at scale

• No security hardening no helmet, no cors, no protection

My only goal with this one was to convey that frameworks aren’t magic, Its just someone’s organized code, and express has really organised our way of writing code.

The Hidden Link Every Object Carries

Here's the part they don't teach clearly every object in JavaScript has a secret connection to another object. Behind the scenes, there's an internal link called [[Prototype]]. You can't touch it directly, but you can peek at it.

const user = { name: "Chirag" };
console.log(Object.getPrototypeOf(user));

There's also this old, informal way. The point is thi when JavaScript looks for a property on user and doesn't find it, it doesn't give up. It follows that hidden link upward. It checks the next object. And the next. This chain lookup is the engine that makes JavaScript inheritance work.

Following the Chain

Let's trace what actually happens when you run user.toString().

First, JavaScript checks user itself. No toString there. So it hops up to user.__proto__, which points to Object.prototype. toString lives there. If it hadn't found it? It would keep climbing. The chain goes: user - Object.prototype -null. null means stop. End of the road. If the property isn't found by then, you get undefined.

The Part Where Functions Get Weird

Okay, here's where people usually get lost. Functions in JavaScript have a prototype property. But that's not the same as __proto__.

function User(name) {
  this.name = name;
}

User.prototype.sayHello = function () {
  return `Hello ${this.name}`;
};

const u1 = new User("Arpit");
console.log(u1.sayHello()); 

// "Hello Arpit"

What does new actually do? Four things creates an empty object, links its __proto__ to User.prototype, binds this to that new object, and returns it. That's it. The User.prototype object becomes the prototype for every instance you create. So u1 doesn't carry sayHello around in its pocket. It borrows it from User.prototype. One method, shared across every user. That's the memory efficiency people talk about.

ES6 gave us the class keyword, and it looks clean -

class User {
  constructor(name) {
    this.name = name;
  }

  sayHello() {
    return `Hello ${this.name}`;
  }
}

Why Any of This Actually Matters

In real systems, prototypes aren't academic trivia. They're practical tools with real consequences.

Memory efficiency first - When you put methods on a prototype, every instance shares one function object. Put them in the constructor with this.method and you're duplicating that function for every single instance. At scale this is what matters(a lot )

Performance next - Deep prototype chains slow down property lookup. If your object inherits from something that inherits from something else, JavaScript has to climb more links. Usually negligible, but worth knowing if you're optimizing hot paths.

The Takeaway

Prototypes aren't some dusty JavaScript quirk. They're the living mechanism behind every method call, every inheritance chain, every class you write. Objects delegate upward. The chain ends at null. Functions have a prototype property that becomes the __proto__ of their instances.

Forget "paradigm" and "abstraction layers." Let's keep it real, OOP is just grouping related stuff together like how life actually works.

Your coffee mug? It has properties (colour, size) and does things (holds coffee, gets warm). You don't store its colour in one drawer and its "hold-coffee" ability in another room. That'd be wild.

Code should feel the same.

The "Four Pillars" of OOP

Encapsulation = Keep Your Stuff in Your Lane

Your bank account balance isn't scribbled on a sticky note everyone can grab. You deposit or withdraw through the bank. this is how it looks in code -

class BankAccount {
  #balance = 0;  

  deposit(amount) {
    if (amount > 0) this.#balance += amount;
  }

  getBalance() {
    return this.#balance;
  }
}

Abstraction = Don't Sweat the Small Stuff

You drive a car. You press the gas pedal. You don't need to know about fuel injectors, piston timing, or transmission fluid. Thank goodness. Again lets see the code -

class PaymentProcessor {
  process(amount) {
    this.validate(amount);
    this.chargeCard(amount);
    this.sendReceipt();
  }


  validate(amount) { /* ... */ }
  chargeCard(amount) { /* ... */ }
}

// Using it:
processor.process(29.99);

You call process(29.99). Done. It just works.

Inheritance = Stand on Shoulders, Don't Reinvent

Your kid inherits your eye color and learns to ride a bike from you. They add their own flair.

class Animal {
  constructor(name) {
    this.name = name;
  }

  speak() {
    console.log(`${this.name} makes a sound`);
  }
}

class Dog extends Animal {
  speak() {
    console.log(`${this.name} barks!`);
  }
}

const buddy = new Dog("Buddy");
buddy.speak(); 

 // "Buddy barks!"

Polymorphism = Same Button, Different Magic

Press "play" on Netflix, show starts. Press "play" on Spotify, music flows. Same button. Smart behavior.

class Notification {
  send() {
    throw new Error("Subclasses must implement send()");
  }
}

class EmailNotification extends Notification {
  send() {
    console.log("Sending email...");
  }
}

class SMSNotification extends Notification {
  send() {
    console.log("Sending text...");
  }
}


function trigger(notification) {
  notification.send(); 
}

trigger(new EmailNotification()); 
trigger(new SMSNotification());

Add a new notification type tomorrow? Zero changes to trigger(). That's the flexibility it provides.

And the classic debate javascript isn’t really OOP, ahh . The truth is under the hood, prototypes are doing the heavy lifting. But since ES6, We get class syntax and it's quite readable.

Basically it either -

1. Take a function as input

2. returns a function

Most of the time, it does both. But even doing one of those things makes it "higher-order."

Think of it like this: regular functions work with data numbers, strings, objects. Higher-order functions work with behavior. Here's the thing that makes JavaScript special, functions are first-class citizens.

In some languages, functions are these rigid, special things. In JavaScript, a function is just another piece of data you can move around. That's why higher-order functions are so natural here we're not fighting the language, we're using it the way it was designed.

Let's Look at Some Basic Examples

Passing a Function as an Argument

This is probably the easiest place to start.

function greet(name) {
  return `Hey there, ${name}!`;
}

function formalGreet(name) {
  return `Good evening, ${name}.`;
}

function saySomething(name, greetingFunction) {
  return greetingFunction(name);
}


console.log(saySomething("Sam", greet));        // "Hey there, Sam!"
console.log(saySomething("Sam", formalGreet));  // "Good evening, Sam."

Returning a Function

function makeMultiplier(factor) {
  return function(number) {
    return number * factor;
  };
}

const triple = makeMultiplier(3);
const double = makeMultiplier(2);

console.log(triple(5));   // 15
console.log(double(5));   // 10

makeMultiplier is like a little factory. You tell it what factor you want, and it builds you a custom function that remembers that factor.

The Built-In HOF

JavaScript gives us three classics that pretty much every developer uses daily. Map, Filter, Reduce.

Lets start with MAP

Use map when you have an array and want to turn every item into something else. Same number of items, different values.

const prices = [10, 20, 30];
const withTax = prices.map(price => price * 1.2);

// [12, 24, 36]

Next is FILTER

Use filter when you want to remove stuff based on a condition. You might end up with fewer items than you started with.

const ages = [15, 22, 18, 30, 12];
const adults = ages.filter(age => age >= 18);

// [22, 18, 30]

REDUCE

Use reduce when you want to take a whole array and collapse it into one value. Could be a sum, an object, whatever.

const numbers = [1, 2, 3, 4];
const sum = numbers.reduce((total, num) => total + num, 0);

// 10

The key thing: don't get hung up on memorizing syntax. Focus on intent. When you look at a problem, ask yourself: "Am I transforming, selecting, or aggregating?" That tells you which tool to grab.

Closures: How Functions Remember Things

When a function is created inside another function, it keeps access to all the variables from its parent even after the parent finishes. It's like the inner function carries a backpack with all the stuff it needs.

function createCounter() {
  let count = 0;  

  return {
    increment: function() {
      count++;
      return count;
    },
    decrement: function() {
      count--;
      return count;
    },
    getCount: function() {
      return count;
    }
  };
}

const myCounter = createCounter();

console.log(myCounter.increment());  // 1
console.log(myCounter.increment());  // 2
console.log(myCounter.getCount());   // 2
console.log(myCounter.decrement());  // 1


console.log(myCounter.count);        // undefined (it's protected!)

Nothing from the outside can touch it directly, but the functions we returned can still use it. This is a classic pattern for creating configurable, stateful behavior while keeping your data safe.

function createLogger(prefix) {
  return function(message) {
    console.log(`[${prefix}] ${message}`);
  };
}

const apiLogger = createLogger("API");
const dbLogger = createLogger("DATABASE");

apiLogger("Request received");     
dbLogger("Connection failed");

Real-World Stuff You'll Actually Use

Logging Wrappers

Want to log how long a function takes without cluttering your business logic? here is an example

function withTiming(fn) {
  return function(...args) {
    const start = Date.now();
    const result = fn(...args);
    const end = Date.now();
    console.log(`${fn.name} took ${end - start}ms`);
    return result;
  };
}

const slowFunction = () => {
  // ... some heavy work
};

const timedSlowFunction = withTiming(slowFunction);
timedSlowFunction();  // Logs: "slowFunction took 45ms"

Retry Logic

APIs fail sometimes. Let's make a wrapper that tries again -

function withRetry(fn, maxAttempts = 3) {
  return async function(...args) {
    for (let i = 1; i <= maxAttempts; i++) {
      try {
        return await fn(...args);
      } catch (error) {
        if (i === maxAttempts) throw error;
        console.log(`Attempt ${i} failed, retrying...`);
      }
    }
  };
}

const fetchWithRetry = withRetry(fetchUserData, 3);

Higher order functions aren't some academic CS concept they're just functions that work with other functions. JavaScript makes this easy because functions are just values we can pass around.

Think of primitives like the basic Lego pieces. They're simple, they're straight forward, and you can't break them down further.

• Strings - “hello“

• Numbers - 24

• Booleans - True/False

these are the simplest ones, nothing fancy.

Undefined - This is JavaScript saying "I've got nothing for you." It's what you get when something doesn't exist in memory yet. No box, no label, just... nothing.

Null - This is intentional nothing. It's you saying, "This should be empty." Which brings us to the Weirdest Thing in JavaScript(one of many weird parts, haha).

typeof null === "object"

It's basically a bug from JavaScript's early days that they can't fix now because it would break the entire internet. Back in 1995, when Brendan Eich was creating JavaScript in about 10 days (seriously), values were stored with a type tag. The tag for objects was 0, and null was represented as 0x00 in most platforms which made it look like an object. Oops. Now we're stuck with it.

Reference Types

Unlike primitives (which are just values), objects, arrays, and functions are references.Lets dig deep. Think of it like this, If I have a primitive, I'm holding the actual Lego piece. If I have an object, I'm holding a map to where the Lego castle is built. Two people can have the same map pointing to the same castle. If one person rearranges the castle, everyone with that map sees the changes.

let person = { name: 'Alex' }
let anotherPerson = person
anotherPerson.name = 'Jordan'
console.log(person.name) 

// Output 
// 'Jordan' - wait, what?!

Variables

var, let, const, why three ways to do the same thing?

var - The old way. It's like that friend who shows up uninvited to parties. var doesn't respect boundaries (block scope, hehe), it gets hoisted to the top (more on that soon), and it's just generally messy. Don't use it unless you're maintaining ancient code.

let & const: They respect block scope (anything inside {}, is a block).

Here's the real talk about const - It doesn't mean "immutable." It means "this reference can't change." You can't reassign the variable, but if it points to an object? You can change that object all day long(typical javascript nvm).

const myArray = []
myArray.push('surprise!') 
// Totally fine
myArray = ['new'] 
// Error! Can't reassign

Temporal Dead Zone - Fancy term for a simple concept. With let and const, you can't use them before they're declared. The space between the start of the scope and the declaration is the "dead zone."

Use const by default. Use let when you need to reassign. Use var never. and stay happy.

Execution Context

Every time a function runs, it gets its own little stage with its own props.

Global Context: The main stage. When your script starts, this is created first.

Function Context: Every function call gets its own mini-stage stacked on top.

The Call Stack: Imagine stacking plates. Each function call is a plate. When it's done, the plate is removed. Last in, first out. This is why infinite recursion breaks things, you run out of plates (stack overflow).

Here's the secret sauce: JavaScript runs in two phases.

1. Memory Phase: JavaScript scans the code and says, "Okay, I see variables and functions. I'll set aside space for them."

2. Execution Phase: Then it actually runs the code, line by line.

Hoisting

During the memory phase, JavaScript sets aside space. var variables: Get hoisted and initialized with undefined.

console.log(name) // undefined, not an error
var name = 'Alex'

let/const: Get hoisted but not initialized. That's why you get a reference error instead of undefined. Temporal deadzone in action.

Function declarations: Get fully hoisted. You can call them before they're defined.

sayHi() // Error!
let sayHi = function() { console.log('hi') }

Function expressions: Don't get hoisted (they're just variables).

SCOPE

Scope is about who can see what. JavaScript has three types:

Global: The outside world. Anything out here is visible everywhere

Function: Variables inside a function are only visible there.

Block: Anything inside {} when using let/const.

Lexical Scoping: Fancy term meaning "where you write it matters." Inner functions can see outer variables, but not vice versa.

Closures - The Magic Trick

Here's where JavaScript becomes interesting. A closure is when a function remembers and accesses variables from outside its own scope, even after that outer function has finished.

function createCounter() {
  let count = 0 

  return function() {
    count++ 
    return count
  }
}

const counter = createCounter()
console.log(counter()) // 1
console.log(counter()) // 2

Real uses: Private variables (like above), event handlers that need to remember stuff, callbacks.

The catch: Closures keep memory alive. If you're not careful, you can create memory leaks. But 99% of the time, it's fine.

Functions

Functions in JS are first class citizens. They can be assigned, passed around, returned just like any other value. cool right !

// Declaration - hoisted
function walk() {}

// Expression - just a value
const run = function() {}

Arrow functions: Shorter syntax, no this of their own (they inherit it), no arguments object. Great for callbacks, not great for methods that need this.

Parameters vs Arguments: Parameters are the recipe, arguments are the ingredients you actually use.

Default parameters: Life-changing. function greet(name = 'stranger') {}

Rest parameters: When you want "the rest of them." function sum(...numbers) {}

Higher-Order Functions

A higher-order function is either -

1. A function that takes another function as input

2. A function that returns a function

// Instead of this:
const doubled = []
for (let i = 0; i < numbers.length; i++) {
  doubled.push(numbers[i] * 2)
}

// You write this:
const doubled = numbers.map(n => n * 2)

map Transform each item in an array
filter Keep only what you want
reduce Boil it down to one value

I'm not saying you need to memorize all this. Hell, I still Google the weird parts sometimes, I did a lot of googling for this as well. But understanding these concepts is like having a map in a foreign city. You might still take wrong turns.

In this we are gonna -

• Understand what HTTP actually is

• Build a server from scratch

• Parse routes manually

• Read headers

• Handle request bodies using streams

• Send proper status codes

what is HTTP ?

Starting with the most important/basic thing, what http is actually ? HTTP is just a conversation protocol.

Every HTTP request has:

• Method (GET, POST, PUT, etc etc)

• URL

• Headers

• Body (optional)

Every HTTP response has:

• Status code (200, 404, 500…)

• Headers

• Body

Creating the smallest possible HTTP server

starting with most basic one

const http = require("http");

const server = http.createServer((req, res) => {
  res.end("Hello World");
});

server.listen(3000, () => {
  console.log("Server running on port 3000");
});

Understanding req and res

req (Incoming Message)

And it mostly contains -

• req.method

• req.url

• req.headers

• request body as a stream

res (Server response)

It is Used to -

• set status codes

• set headers

• send response body

Routing in nodejs

const server = http.createServer((req, res) => {
  if (req.method === "GET" && req.url === "/") {
    res.end("Home page");
    return;
  }

  if (req.method === "GET" && req.url === "/health") {
    res.end("OK");
    return;
  }

  res.statusCode = 404;
  res.end("Not Found");
});

Routing is just if-else on method and path(i love this analogy, got it from a cohort and still carry with me). Every framework eventually does this just in a cleaner way.

Reading request headers

Headers are metadata.

Auth tokens, content type, user agent all comes through headers.

const server = http.createServer((req, res) => {
  console.log(req.headers);

  res.end("Check your terminal");
});
/* output you'll see in terminal. it might differ a bit
content-type
authorization
user-agent
content-length
*/

Handling request body

Request body is a stream. The body does not come all at once. It arrives in chunks.

const server = http.createServer((req, res) => {
  let body = "";

  req.on("data", (chunk) => {
    body += chunk;
  });

  req.on("end", () => {
    console.log(body);
    res.end("Body received");
  });
});

This pattern matters a lot in real systems. Because -

• Requests can be huge

• Streaming avoids loading everything in memory

• This scales better

Parsing JSON request body

req.on("end", () => {
  try {
    const data = JSON.parse(body);
    console.log(data);
    res.end("JSON parsed");
  } catch (err) {
    res.statusCode = 400;
    res.end("Invalid JSON");
  }
});

On eimportant thing to notice here is that you are responsible for validations here, frameworks just hide these from us.

Sending proper status codes

res.statusCode = 201;
res.end("User created");

Some common status codes with meaning

• 200 – OK

• 201 – Created

• 400 – Bad request

• 401 – Unauthorized

• 404 – Not found

• 500 – Server error

Setting response headers

Headers go out before body

res.setHeader("Content-Type", "application/json");
res.statusCode = 200;
res.end(JSON.stringify({ message: "Hello" }));

Order doesn’t matter in code that much. Node sends them correctly under the hood.

A tiny but complete server

Putting everything together

const http = require("http");

const server = http.createServer((req, res) => {
  if (req.method === "POST" && req.url === "/echo") {
    let body = "";

    req.on("data", (chunk) => {
      body += chunk;
    });

    req.on("end", () => {
      res.setHeader("Content-Type", "application/json");
      res.statusCode = 200;
      res.end(body);
    });

    return;
  }

  res.statusCode = 404;
  res.end("Route not found");
});

server.listen(3000);

Once we understand these foundations of a server Frameworks stop feeling magical. Debugging becomes easier. Performance issues make sense.

before getting started, two important questions to answer.

1. Is nodejs single-threaded ?
YES

2. Node.js is also non-blocking.
YES

What the Event Loop really is

Think of the Event Loop as:

A disciplined scheduler that decides what code runs next and when

It repeatedly does this:

1. Take one task

2. Run it to completion

3. Pick the next task based on strict rules

4. Repeat forever

The event loop is like a conductor in an orchestra it doesn't play instruments itself, but it coordinates when each section (or phase) gets to perform. Every time the event loop completes one full cycle through all phases, we call that a tick.

The Six Phases

Phase 1: Timers Phase

What happens here - This phase executes callbacks scheduled by setTimeout() and setInterval() once their timer expires.

Key details:

• If you set setTimeout(callback, 0), it doesn't mean "run immediately." It means "run in the next tick's timers phase."

• The event loop checks if the timer's time has elapsed, and if so, executes those callbacks.

• If one or more timers are ready, the event loop will wrap back to this phase to execute those timers' callbacks.

Phase 2: Pending Callbacks Phase

What happens here: Executes I/O callbacks that were deferred to the next loop iteration. Think of this as your "pending mail" folder. Some I/O operations (like TCP errors, certain file system operations) couldn't be handled immediately in the poll phase, so they're queued here for the next cycle.

Key details:

• This phase handles callbacks that couldn't be processed in the previous poll phase.

• Examples include certain types of TCP errors or operations that the system couldn't complete right away.

• It's essentially a "catch-up" phase for I/O that needs attention but wasn't ready during the last poll.

Phase 3: Idle, Prepare Phase

What happens here: This phase is used internally by Node.js and libuv. This is like the orchestra's tuning phase musicians adjust their instruments before the main performance. You don't see it, but it's essential for everything to work smoothly.

Key details:

• Idle phase: Used internally by libuv for housekeeping tasks.

• Prepare phase: Also internal, used to prepare for the upcoming poll phase.

• As a developer, you typically don't interact with this phase directly it's all behind the scenes magic.

Phase 4: Poll Phase Most important one

What happens here: This is the core phase where Node.js retrieves new I/O events and executes their callbacks.

Key details:

It has two main responsibilities:

1. Calculate how long it should block and poll for I/O: The event loop figures out how long to wait for new events.

2. Process I/O events in the poll queue: When I/O events are ready, their callbacks get executed here.

Also, it has a special behviour as well. f there are setImmediate() callbacks waiting AND the poll queue is empty, Node.js will immediately exit the poll phase and move to the check phase.
If timers are ready to fire, Node.js will wrap back to the timers phase after the poll phase completes. It can be made predictible. We’ll see that through code snippets.

Phase 5: Check Phase

What happens here: Executes callbacks scheduled by setImmediate(). Key details:

• setImmediate() callbacks are designed to execute after I/O callbacks but before the next tick's timers.

• This phase exists specifically to allow developers to schedule callbacks that run right after the poll phase.

• If you have both setTimeout(callback, 0) and setImmediate(callback), the order depends on context—usually setTimeout fires first when called from the main module, but setImmediate can win inside I/O callbacks.

Phase 6: Close Callbacks Phase

What happens here: Handles "close" events and cleanup operations. For instance, a connection being terminated or a socket.close event.

Lets look at the complete cycle in action -

And the best way to understand this is to play classic “guess the output“ game

console.log(' Start');

// Timers phase
setTimeout(() => console.log(' setTimeout (timers phase)'), 0);

// Check phase
setImmediate(() => console.log('setImmediate (check phase)'));

// Poll phase (I/O callback)
require('fs').readFile(__filename, () => {
    console.log('readFile callback (poll phase)');
    setImmediate(() => console.log(' Nested setImmediate'));
});

// Close callbacks phase
const net = require('net');
const server = net.createServer();
server.listen(0, () => {
    server.close(() => {
        console.log('🚪 Close callback (close callbacks phase)');
    });
});

console.log('End');

/// * Output 
 Start
 End
 readFile callback (poll phase)
 setImmediate (check phase)
 Close callback (close callbacks phase)
 setTimeout (timers phase)
 Nested setImmediate
 /// *

The Takeaway

it's a very well-organized system with six distinct phases:

1. Timers - Scheduled timeouts and intervals

2. Pending Callbacks -Deferred I/O callbacks

3. Idle/Prepare - Internal housekeeping

4. Poll - The heart of I/O processing (where Node spends most time!)

5. Check - setImmediate() callbacks

6. Close Callbacks - Cleanup and resource destruction.

he event loop is powered by libuv a C library that handles all the low-level I/O operations and threading. Node.js sits on top of libuv, providing the JavaScript interface we all love. The Node.js official documentation has amazing diagrams of the event loop. Check it out if you want to go even deeper, I took a lot of inspiration from there and some other great blogs out there.