In this blog we will understand why file uploads need middleware, what Multer is, how to handle single and multiple file uploads, how to configure storage properly, and how to serve uploaded files back to users.

First, let’s understand why file uploads need middleware.

Why File Uploads Need Middleware

When a standard HTML form submits text data, browsers usually send it as application/x-www-form-urlencoded or application/json. Express can parse these formats easily using built-in middleware like express.json() or express.urlencoded(). But files are completely different.

Browsers send files using multipart/form-data. This format splits the request into multiple parts: text fields, file metadata, and the actual binary file stream. Express does not parse multipart/form-data by default. If you try to access req.body or req.files without middleware, you will get undefined.

That is where middleware comes in. It intercepts the incoming request, reads the multipart stream, extracts the files safely, and attaches them to the request object. Without this step, your server would have to manually handle binary chunks, manage temporary files, and prevent memory leaks. Middleware abstracts all of that complexity so you can focus on your application logic.

Now let’s understand what Multer is.

What is Multer?

Multer is a Node.js middleware built specifically for handling multipart/form-data. It is the most popular and widely recommended solution for file uploads in Express.

Multer parses incoming requests, extracts files, and gives you full control over where and how those files are stored. It also provides built-in safety features like file size limits, field validation, and error handling. Without Multer, you would need to write custom stream parsers, manage disk cleanup, and handle edge cases manually. Multer turns a complex, error-prone process into a few lines of clean configuration.

Before we upload anything, we need to decide where files should go.

Storage Configuration Basics

Multer gives you two main storage engines: memory storage and disk storage.

Memory storage keeps uploaded files in RAM as Buffer objects. It is fast and useful for small files or when you want to pipe data directly to cloud storage. But it is not safe for production apps because large uploads can exhaust your server memory and crash the process.

Disk storage saves files directly to your server’s file system. This is the recommended approach for most beginners and small-to-medium projects. You configure it using multer.diskStorage(), where you define two things:

• destination: The folder where files will be saved

• filename: How the saved file should be named

By default, Multer generates random filenames without extensions. To keep things organized, you can preserve the original extension, add timestamps, or generate unique IDs. Proper filename configuration prevents collisions and makes future file management much easier.

Now let’s understand how to handle a single file upload.

Handling Single File Upload

Once Multer is installed (npm install multer) and storage is configured, you can attach it to your routes as middleware.

For a single file, you use upload.single('fieldName'). The fieldName must match the name attribute in your HTML form or frontend API request. When the request reaches your route, Multer processes the file, saves it to disk, and attaches metadata to req.file.

You can then access useful properties like:

• req.file.filename: The saved name on disk

• req.file.path: The full file path

• req.file.size: File size in bytes

• req.file.mimetype: The detected file type

If the field is missing or the file exceeds your configured limits, Multer throws an error that you can catch and return as a clean JSON response. This makes single file uploads predictable, secure, and easy to debug.

What if users need to upload more than one file?

Handling Multiple File Uploads

Multer handles multiple uploads smoothly without changing your core setup.

If users upload several files from the same form field, use upload.array('fieldName', maxCount). The maxCount parameter limits how many files can be sent at once, which helps prevent abuse and server overload. After processing, Multer attaches an array of file objects to req.files instead of a single req.file. You can loop through this array to save records to a database, generate access URLs, or run validation checks.

If your form contains multiple different file fields (for example, avatar and documents), you can use upload.fields(). You pass an array of objects defining each field name and its maximum count. Multer then organizes the results into req.files as an object where each key holds its own array of files.

This structure keeps complex upload forms clean and prevents route handlers from becoming messy.

Uploading files is only half the process. Users also need to access them.

Serving Uploaded Files

To serve uploaded files, you can use Express’s built-in express.static() middleware. Point it to your upload directory, and Express will automatically serve files when users request the correct URL.

For example, if your files are saved in an uploads/ folder, mounting app.use('/uploads', express.static('uploads')) allows users to access a file via http://localhost:3000/uploads/filename.jpg. The browser will render images, download documents, or play media depending on the file type.

In production, you should follow a few security best practices:

• Never execute or trust uploaded files blindly

• Validate file types on both frontend and backend

• Restrict upload sizes to prevent disk exhaustion

• Consider moving to cloud storage like AWS S3, Cloudinary, or Firebase for better scalability, CDN delivery, and automatic backups

Serving files statically works perfectly for learning and small projects, but cloud storage handles traffic spikes, security, and global delivery more efficiently as your app grows.

Conclusion

File uploads are a common requirement, but they require careful handling to stay secure, efficient, and scalable. Multer removes the complexity of parsing multipart data and gives you a clean, reliable way to manage uploads in Express. By configuring storage properly, handling single and multiple files correctly, and serving them safely, you can build robust upload features without reinventing the wheel.

Understanding this flow gives you a clear picture of how modern web apps manage user-generated content, how to protect your server from malformed requests, and how to scale your upload system as your application grows. Start with disk storage, add validation, and move to cloud providers when you are ready. The rest is just practice.

What Authentication Means

Authentication is the process of verifying a user’s identity. When someone submits their credentials, the system checks whether they are who they claim to be. It’s crucial to distinguish authentication from authorization: authentication answers “Who are you?” while authorization answers “What are you allowed to do?”

Think of authentication as showing your ID at a building’s front desk. Authorization is the access badge that decides which floors you can visit once inside. Without reliable authentication, malicious actors could easily impersonate legitimate users. JWTs solve this by providing a secure, cryptographically verifiable way to confirm identity across multiple requests without storing session data on the server.

What is a JWT?

A JWT (pronounced “jot”) is a compact, URL-safe token that securely represents claims between two parties. Unlike traditional session-based authentication, which stores user state on the server or in a database, JWTs are stateless.

Here’s how it works: after a successful login, your server generates a JWT and sends it to the client. The client stores it and attaches it to every subsequent request. The server doesn’t need to query a session store; it simply verifies the token’s signature to trust the claims inside. This makes JWTs highly efficient for RESTful APIs, mobile apps, and microservice architectures where scaling and performance matter.

Structure of a JWT

A JWT isn’t a random string of characters. It’s composed of three distinct parts, separated by dots: header.payload.signature. Each part is Base64Url encoded, which is why tokens look like long, unreadable sequences.

Header

The header contains metadata about the token. It typically specifies the signing algorithm and the token type.

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload

The payload holds the actual claims, statements about the user and token metadata. Common standard claims include sub (subject/user ID), iat (issued at), and exp (expiration time). You can also include custom data. For example:

{
  "sub": "user_101",
  "name": "Suprabhat", age: 23,
  "role": "member",
  "iat": 1715000000,
  "exp": 1715003600
}

Important: Payloads are encoded, not encrypted. Anyone can decode them using online tools. Never store sensitive information like passwords, credit card numbers, or private keys in a JWT.

Signature

The signature is the security backbone of the token. It’s created by taking the encoded header and payload, combining them with a secret key known only to your server, and running them through the algorithm specified in the header (e.g., HMAC-SHA256). If an attacker modifies the header or payload, the signature will no longer match, and the server will immediately reject the token.

The JWT Login Flow

Let’s walk through how this works in practice using our example user: name: "Suprabhat", age: 23,.

1. Login Request: Suprabhat enters their email and password on the frontend and submits a POST request to your Node.js /api/login endpoint.

2. Credential Verification: Your server queries the database, hashes the submitted password, and compares it with the stored hash.

3. Token Generation: If the credentials match, the server generates a JWT. It includes a unique user identifier, sets an expiration time (e.g., 1 hour), and signs it with a secure secret key.

4. Response Delivery: The server sends the JWT back to the client, usually in the JSON response body or as a secure HTTP-only cookie.

5. Client Storage: The frontend securely stores the token (commonly in memory or localStorage, depending on your security model).

From this point forward, Suprabhat won’t need to log in again until the token expires. The JWT acts as a temporary, cryptographically verified digital ID card.

Sending Tokens with Requests

Once the client holds the JWT, it must attach it to every request that requires authentication. The industry standard is using the Authorization HTTP header with the Bearer scheme:

GET /api/dashboard
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEwMSJ9...

Modern frontend frameworks handle this automatically. For example, using Axios, you can set up a request interceptor that reads the stored token and attaches it before every API call.

Security Tip: Never pass JWTs in URL query parameters. URLs are logged in browser history, server logs, and proxy caches, making tokens highly vulnerable to leakage.

Protecting Routes in Node.js

Now, let’s see how your Node.js server verifies incoming tokens. You’ll typically use the official jsonwebtoken package to build a reusable middleware function.

const jwt = require('jsonwebtoken');

const authenticateToken = (req, res, next) => {
  const authHeader = req.headers['authorization'];
  const token = authHeader && authHeader.split(' ')[1]; // Extracts "Bearer <token>"

  if (!token) {
    return res.status(401).json({ error: 'Authentication required' });
  }

  jwt.verify(token, process.env.JWT_SECRET, (err, user) => {
    if (err) {
      return res.status(403).json({ error: 'Invalid or expired token' });
    }
    req.user = user; // Attach decoded payload to the request object
    next(); // Proceed to the actual route handler
  });
};

// Apply middleware to protected routes
app.get('/api/profile', authenticateToken, (req, res) => {
  res.json({ message: `Welcome, ${req.user.name}!` });
});

This middleware checks for the presence of a token, verifies its cryptographic signature, and ensures it hasn’t expired. If valid, it attaches the decoded payload to req.user, making user data available to your route handlers. If invalid, it short-circuits the request with a clear HTTP status code.

Conclusion

JWT authentication might sound intimidating at first, but it’s fundamentally just a secure, standardized way to pass verified user data between client and server. By understanding its three-part structure, mastering the login flow, and implementing clean verification middleware in Node.js, you can build scalable, stateless APIs with confidence.

Always follow security best practices: use strong, randomly generated secret keys, set reasonable token expiration times, implement token refresh strategies for longer sessions, and never expose sensitive data in the payload. With these foundations in place, you’re well-equipped to secure your next Node.js application like a pro.

First, let’s understand what is blocking code and why it matters.

What is blocking code and why it matters

Blocking code runs synchronously. This means the program stops and waits for an operation to finish before moving to the next line. If a task takes five seconds to complete, the entire JavaScript thread pauses for five seconds.

In Node.js, this is dangerous because there is only one main thread. When the thread is blocked, the Event Loop cannot pick up new requests, process timers, or handle any other callbacks. The server appears frozen to all users until the blocking task finishes.

Common examples of blocking code include:

• fs.readFileSync() for file operations

• crypto.pbkdf2Sync() for password hashing

• Heavy for or while loops with complex calculations

• Synchronous database queries in older drivers

While blocking code is simple to read and debug, it does not scale. A single slow file read or a complex math operation can delay hundreds of other requests waiting in line. Beginners often use blocking methods because they look straightforward, but in production servers, they become performance bottlenecks.

What is non-blocking code and how it works

Non-blocking code runs asynchronously. Instead of waiting for a task to finish, Node.js hands the operation to Libuv in the background and immediately continues executing the next lines of code.

When the background task completes, the result is placed in the Callback Queue. The Event Loop later picks it up and runs the callback or resolves the promise. This keeps the main thread free to handle other incoming requests.

Examples of non-blocking code include:

• fs.readFile() with callbacks or promises

• fetch() or axios for HTTP requests

• Database queries using async/await

• setTimeout() and setInterval() for delayed execution

Non-blocking code does not mean the task finishes faster. It means the server does not waste time waiting. It can serve other users while the background work completes. This is why Node.js excels at I/O-heavy applications like APIs, real-time chats, and streaming services.

A common point of confusion is async/await. It looks synchronous when you read it, but it is completely non-blocking. The await keyword pauses only the current function, not the entire Event Loop. Other requests continue processing normally.

Step by step comparison with practical examples

Let’s compare both approaches using a simple file read operation.

Blocking version:

const fs = require('fs');
const data = fs.readFileSync('users.json', 'utf8');
console.log('File read finished');
console.log(data);

In this code, the program stops at readFileSync(). It waits until the entire file is loaded into memory. Only then does it print the logs. If another user sends a request during this wait, the server ignores it until the file read completes.

Non-blocking version:

const fs = require('fs').promises;
fs.readFile('users.json', 'utf8')
  .then(data => console.log(data))
  .catch(err => console.error(err));
console.log('File read started');

Here, readFile() starts the operation and immediately moves to the next line. The console prints "File read started" right away. When the file finishes loading in the background, the .then() callback runs. The Event Loop stays free to process other tasks in the meantime.

The same principle applies to database calls, API requests, and network operations. Non-blocking code keeps the application responsive under load.

How blocking and non-blocking code affect the Event Loop

The Event Loop is designed to stay fast and continuous. It constantly checks the Call Stack, moves tasks from the Callback Queue, and runs them one by one.

When you use blocking code, you freeze the Call Stack. The Event Loop cannot move to the next phase. Timers delay, pending callbacks stack up, and new requests queue indefinitely. The poll phase stops waiting for I/O because the thread is busy running synchronous code. Even setTimeout callbacks will not fire until the blocking operation finishes.

When you use non-blocking code, the Event Loop flows smoothly. I/O tasks go to Libuv, the main thread stays empty, and the loop continues cycling through phases. Completed tasks enter the queue and get executed without interrupting other operations. The poll phase efficiently waits for I/O events and immediately processes them when ready.

This is why writing non-blocking code is not just a best practice in Node.js. It is a requirement for performance.

Common mistakes beginners make

Many developers new to Node.js accidentally block the Event Loop without realizing it. Here are the most frequent pitfalls:

• Using sync methods in route handlers: fs.readFileSync() inside an Express route will freeze that route for every user.

• Heavy JSON parsing: JSON.parse() on a massive payload runs on the main thread and blocks other requests.

• Complex loops: Nested for loops with thousands of iterations consume CPU and stop the loop from checking the queue.

• Ignoring promise rejections: Unhandled promise rejections do not block the loop immediately, but they cause memory leaks and eventual crashes.

To avoid these, always profile your code, use streaming for large files, and move CPU-heavy work outside the main thread.

When to use blocking vs non-blocking code

Choosing the right approach depends on your use case.

Use non-blocking code for:

• File reads and writes in web servers

• Database queries and API calls

• Network requests and WebSocket messages

• Any I/O operation that involves waiting for external systems

Use blocking code only for:

• Simple scripts or CLI tools where performance does not matter

• Application startup tasks that must finish before the server begins listening

• Configuration file reads that happen once during initialization

If you must run heavy CPU tasks like image processing, video encoding, or complex data analysis, do not block the main thread. Instead, use Worker Threads or Child Processes. These run in separate threads and communicate with the main process without freezing the Event Loop.

Connecting blocking vs non-blocking to real user requests

When a user interacts with your application, the difference becomes obvious.

Let’s imagine a user named: "Suprabhat", age: 23, tries to log into a web application. The server needs to read his profile data from a JSON file and verify his password.

If the server uses blocking code: Suprabhat clicks login. The server calls readFileSync() and hashSync(). The entire thread pauses. If another user tries to register at the same time, their request waits. Suprabhat’s page hangs until both operations finish. Under heavy traffic, the server times out and returns 503 errors.

If the server uses non-blocking code: Suprabhat clicks login. The server hands the file read and password check to Libuv. The Event Loop continues handling other requests. When the background tasks finish, the results return to the queue. The Event Loop picks them up, formats the response, and sends it back. Suprabhat gets a fast response, and other users are not affected.

This shows how non-blocking code directly improves user experience and server stability.

Conclusion

Blocking code stops execution and waits. Non-blocking code continues running and handles results later. In a single-threaded environment like Node.js, this difference determines whether your application scales or crashes under load.

Always prefer non-blocking I/O for web servers. Use async/await or promises to keep code clean and readable. Reserve synchronous methods for startup scripts or local tools. For CPU-heavy work, move it to Worker Threads.

Understanding this flow gives a clear picture of how servers manage heavy traffic without freezing. Choosing the right execution model keeps the Event Loop free and ensures every request gets processed smoothly!

First, let’s understand what REST is and why it matters.

What is REST and why it matters

REST stands for Representational State Transfer. It is not a protocol or a framework. It is an architectural style that defines how clients and servers should communicate over HTTP. REST relies on a few core principles that keep APIs predictable and easy to work with.

Resources are the foundation. Every piece of data in your system is treated as a resource, identified by a URL. Instead of calling actions like getUser or createOrder, you work with resources like /users or /orders.

HTTP methods define the action. GET retrieves data, POST creates new records, PUT or PATCH updates existing ones, and DELETE removes them. This standardization means any developer can understand your API just by looking at the route and method.

Stateless communication ensures scalability. Each request contains all the information the server needs. The server does not store session state between requests, which makes horizontal scaling and caching much easier.

When you follow REST principles, your API becomes self-documenting, consistent, and ready for any frontend framework or mobile app.

Mapping REST principles to Express.js routes

Express.js is a minimal Node.js framework that makes routing straightforward. You can map REST concepts directly to Express route handlers.

const express = require('express');
const app = express();
app.use(express.json());

app.get('/users', (req, res) => {
  res.json({ message: 'Fetch all users' });
});

app.post('/users', (req, res) => {
  res.status(201).json({ message: 'User created' });
});

app.get('/users/:id', (req, res) => {
  res.json({ message: `Fetch user ${req.params.id}` });
});

app.put('/users/:id', (req, res) => {
  res.json({ message: `Update user ${req.params.id}` });
});

app.delete('/users/:id', (req, res) => {
  res.status(204).send();
});

This structure mirrors REST perfectly. URLs use plural nouns for collections. Route parameters like :id target specific resources. Each HTTP method triggers the correct operation. Express handles the routing logic while you focus on the business rules.

Step by step API route design

Designing a route goes beyond picking a URL. You need to handle request data, validate inputs, return proper status codes, and format responses consistently.

Use clear URL naming Stick to nouns, not verbs. /users is better than /getUsers. Use nested routes for relationships like /users/:userId/posts.

Handle request data properly POST and PUT requests send data in the request body. Express needs express.json() middleware to parse it. Always validate incoming data before processing it.

Return correct HTTP status codes Status codes tell the client what happened. Use 200 for successful GET/PUT, 201 for successful POST, 204 for successful DELETE with no body, 400 for bad requests, 404 for missing resources, and 500 for server errors.

Standardize JSON responses Keep your response structure consistent. Wrap data in a predictable format so frontend developers know exactly what to expect.

// Success response
{
  "success": true,
  "data": { "id": 1, "name": "Suprabhat" },
  "message": "User fetched successfully"
}

// Error response
{
  "success": false,
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Email is required"
  }
}

This consistency reduces frontend bugs and makes API documentation easier to maintain.

Best practices for clean API design

REST is simple in theory, but real-world projects introduce complexity. Following these practices keeps your API maintainable as it grows.

• Separate routes and controllers: Keep route definitions in one file and business logic in another. This makes testing and debugging easier.

• Use middleware for shared logic: Authentication, logging, and error handling should run as middleware instead of repeating code in every route.

• Handle errors gracefully: Never expose stack traces in production. Create a centralized error handler that catches unhandled exceptions and returns clean JSON responses.

• Version your API: Add /api/v1/ to your base path. This allows you to introduce breaking changes later without disrupting existing clients.

• Avoid over-fetching: Let clients request only the fields they need using query parameters like ?fields=name,email. This reduces payload size and improves performance.

These practices transform a basic Express server into a production-ready API that scales smoothly.

Connecting REST API design to real requests

When a frontend application calls your API, the same routing and response flow happens behind the scenes.

Client → Sends GET /users/123 Express → Matches route and extracts params Controller → Queries database and formats data Middleware → Adds security headers and logs request Server → Returns standardized JSON response

Let’s imagine a user named: "Suprabhat", age: 23, opens a dashboard that fetches his profile data. The frontend sends a GET request to /api/v1/users/123. Express matches the route, the controller queries the database, and the response returns a clean JSON object with his name, age, and preferences. If Suprabhat updates his email, the frontend sends a PATCH request with only the changed field. The server validates the input, updates the record, and returns a 200 status with the new data. Every interaction follows the same predictable pattern, making the system reliable and easy to debug.

Conclusion

REST API design is about consistency, clarity, and leveraging HTTP standards. Express.js makes it straightforward to map resources to routes, handle requests cleanly, and return predictable responses. By following proper naming conventions, status codes, and response formatting, you build APIs that frontend teams and external services can integrate with ease.

Always keep routes modular, validate incoming data, and centralize error handling. Version your endpoints and avoid over-fetching to keep payloads lean. Understanding this flow gives a clear picture of how servers exchange data reliably while staying fast and maintainable.

Choosing the right structure from day one saves hours of refactoring later. With Express.js and REST principles, building scalable APIs becomes a simple, repeatable process!

First, let’s understand what is the Event Loop and why it exists.

What is the Event Loop and why it exists

Node.js is single-threaded. This means it can only execute one piece of JavaScript code at a time. If Node.js had to wait for every database query, file read, or API call to finish before moving to the next line, it would become extremely slow and unresponsive.

To solve this, Node.js uses the Event Loop. It acts like a smart traffic manager that constantly checks if background tasks are finished. When a task completes, the Event Loop picks it up and hands it back to the main thread. This makes Node.js non-blocking and highly efficient for I/O-heavy operations.

Without the Event Loop, we would need multi-threading for every request, which consumes more memory and is harder to manage. The Event Loop gives us the speed of async programming with the simplicity of a single thread.

How the Event Loop works step by step

Before understanding the phases, we need to know the main components that work together behind the scenes.

The Call Stack runs JavaScript code line by line. It is where all your synchronous functions execute. When you call a function, it goes on top of the stack. When it returns, it gets removed.

When an async task like reading a file or making an HTTP request happens, it is handed off to Libuv. Libuv is a C library that handles system-level operations in the background. It manages thread pools, network sockets, and file system operations.

Once the background task finishes, the result is placed in the Callback Queue.

The Event Loop constantly checks one simple question: Is the Call Stack empty?

If yes, it takes the first task from the Callback Queue and pushes it onto the Call Stack. Then the main thread executes it. This cycle repeats endlessly, making Node.js fast and responsive.

Now let’s understand how the Event Loop moves through its different phases.

Understanding the different phases of the Event Loop

The Event Loop does not just pick tasks randomly. It moves through specific phases in a strict order. Each phase has its own purpose and runs callbacks accordingly.

Timers Phase This phase runs callbacks scheduled by setTimeout and setInterval. If you set a timeout for 2000 milliseconds, the Event Loop checks if enough time has passed and executes the callback in this phase.

Pending Callbacks Phase This phase handles certain system operations that could not run in the previous phase. It mainly deals with TCP error messages or network events that need immediate attention.

Poll Phase This is the most important phase. It waits for new I/O events to complete, like reading a file, receiving a database response, or handling incoming requests. If the Callback Queue is empty, the Event Loop will actually pause here until new tasks arrive. This prevents the loop from wasting CPU cycles.

Check Phase This phase runs setImmediate() callbacks. It is used when you want to execute code right after the poll phase completes, without waiting for timers.

Close Callbacks Phase This phase handles cleanup operations. It runs callbacks for closed connections, like socket.on('close') or file stream closures.

After the close phase, the loop checks if there are any active handles or pending requests. If yes, it starts over from the timers phase. If not, the Node.js process exits gracefully.

Understanding process.nextTick and setImmediate

Developers often confuse process.nextTick() and setImmediate(). They look similar but work differently.

process.nextTick() is not part of the Event Loop phases. It runs immediately after the current operation finishes, before the loop moves to the next phase.

setImmediate() runs inside the check phase of the Event Loop.

This means process.nextTick() has higher priority. If you mix both in your code, nextTick callbacks will always run first. This is useful for breaking up long-running tasks or deferring work to the next iteration without leaving the current call context.

How to avoid blocking the Event Loop

Since Node.js runs on a single thread, blocking the Event Loop can freeze your entire application. Heavy synchronous operations like large JSON parsing, complex math calculations, or synchronous file reads will stop the loop from processing other requests.

When to use what:

• Use async/await or Promises for database calls, file operations, and API requests.

• Avoid sync methods like fs.readFileSync in production servers.

• Use worker threads or child processes for CPU-heavy tasks like image processing or data encryption.

This keeps the Event Loop free to handle incoming traffic while heavy work runs in parallel.

Connecting the Event Loop to real Node.js requests

When a user sends a request to your Node.js server, the same Event Loop process happens behind the scenes.

Browser → Sends HTTP request Server → Receives request and places it in the queue Event Loop → Picks up the request and passes I/O work to Libuv Libuv → Handles database query or file read in background Poll Phase → Waits for the database to respond Check Phase → Executes response formatting Server → Sends data back to the browser

Let’s imagine a user named: "Suprabhat", age: 23, logs into a web app. When he clicks login, the server does not stop to wait for the database. It hands the query to Libuv, continues handling other requests, and only returns to format Suprabhat’s profile data once the database replies. This keeps the app fast even under heavy traffic.

So every web request depends on the Event Loop before any response is sent back.

Conclusion

The Event Loop is the hidden engine that makes Node.js fast and scalable. It handles async work smartly by moving heavy tasks to background threads and checking back only when needed. Understanding this flow gives a clear picture of how servers manage heavy traffic without blocking or crashing.

Choosing the right async method depends on what you need. If you need something to run immediately after the current task, use process.nextTick(). If you want to run code in the next loop iteration, use setImmediate(). Understanding these phases helps you see how the "invisible" parts of Node.js work every time your server handles a request!

In this blog, we will understand how to install Node.js, verify the installation using the terminal, explore the Node REPL, create your first JavaScript file, run it using the node command, and finally build a simple Hello World server. By the end, you will have a fully working Node.js setup and your first backend application running locally.

First, let’s understand how to install Node.js.

Installing Node.js

Node.js is an open-source JavaScript runtime that allows you to execute JavaScript code outside the browser. It is built on Chrome’s V8 engine and is widely used for building fast, scalable network applications.

To install Node.js, visit the official website at nodejs.org. You will see two versions available for download: LTS (Long Term Support) and Current. For beginners and production environments, always choose the LTS version. It is stable, well-tested, and receives long-term security updates.

Download the installer for your operating system (Windows, macOS, or Linux) and follow the setup wizard. Keep the default options selected, especially the one that adds Node.js to your system PATH. This step ensures you can run node and npm commands from any terminal window without configuring environment variables manually.

Once the installation finishes, you are ready to verify it.

Checking installation using terminal

After installing Node.js, the next step is to confirm that it was installed correctly. Open your terminal (Command Prompt or PowerShell on Windows, Terminal on macOS/Linux) and type the following command:

node -v

This command asks: What version of Node.js is currently installed on my system?

If the installation was successful, you will see a version number like v24.12.0 The exact number may vary depending on when you install it.

v24.12.0

Node.js also comes bundled with npm (Node Package Manager), which helps you install third-party libraries, manage project dependencies, and run scripts. To check npm, run:

npm -v

You should see a version number like 11.6.2 If both commands return versions without errors, your setup is complete and ready for development.

Now let’s explore an interactive feature of Node.js.

Understanding Node REPL

REPL stands for Read-Eval-Print Loop. It is an interactive command-line environment where you can type JavaScript code, press Enter, and see the result immediately.

To start the REPL, simply type:

node

You will notice the terminal prompt changes to >. This means you are now inside the Node.js environment.

Try typing simple JavaScript expressions:

> 2 + 3
5
> console.log("Hello, Suprabhat")
Hello, Suprabhat
undefined

The REPL reads your input, evaluates it, prints the output, and loops back for the next command. It is extremely useful for testing small code snippets, checking syntax, or experimenting with JavaScript features without creating a file.

To exit the REPL, press Ctrl + C twice or type .exit and press Enter.

While REPL is great for quick tests, real applications are written in files. Let’s create one.

Creating first JS file

Open your favorite code editor (VS Code is highly recommended for beginners). Create a new folder for your project, for example my-first-node-app. Inside this folder, create a new file named app.js.

Now, write a simple JavaScript statement inside the file:

console.log("Welcome to Node.js, Suprabhat!");

Save the file. Unlike browser JavaScript, Node.js does not need an HTML file or a browser window to run. It executes JavaScript directly from your terminal.

Before running it, make sure your terminal is pointing to the correct folder. Use the cd command to navigate:

cd path/to/my-first-node-app

Now you are ready to execute the script.

Running script using node command

To run your JavaScript file, use the node command followed by the filename:

node app.js

Behind the scenes, Node.js reads the file, compiles the JavaScript using the V8 engine, and executes it line by line.

You should see the following output in your terminal:

Welcome to Node.js, Suprabhat!

If you make changes to app.js, you will need to run the node app.js command again to see the updated output. Node.js does not auto-reload by default, which keeps it lightweight and predictable.

This simple workflow, write, save, run, is the foundation of every Node.js application. Now let’s take it one step further and build a real server.

Writing Hello World server

So far, we have run simple scripts. But Node.js shines when it comes to building network servers. Let’s create a basic HTTP server that responds with “Hello World” when you visit it in a browser.

Replace the content of app.js with the following code:

const http = require('http');

const server = http.createServer((req, res) => {
  res.writeHead(200, { 'Content-Type': 'text/plain' });
  res.end('Hello World from Node.js!\n');
});

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

Let’s break down what this code does:

• require('http') loads Node.js’s built-in HTTP module, which handles web requests.

• http.createServer() creates a server that listens for incoming connections.

• The callback function receives req (request) and res (response). Every time someone visits the server, this function runs.

• res.writeHead(200, ...) sets a successful HTTP status code and tells the browser to expect plain text.

• res.end() sends the final response and closes the connection.

• server.listen(3000) starts the server on port 3000 and prints a confirmation message.

Save the file and run it again:

node app.js

You will see:

Server is running at http://localhost:3000

Open your browser and visit http://localhost:3000. You should see “Hello World from Node.js!” displayed on the page.

To stop the server, press Ctrl + C in the terminal.

Connecting your local server to real web requests

When you visit http://localhost:3000 in your browser, the same networking process happens that powers real websites. Your browser sends an HTTP request to your local machine. Node.js receives it, processes it through the server callback, and sends back the response over a TCP connection. Because TCP guarantees delivery and order, your browser receives the exact text you defined in res.end().

This is the exact foundation that scales into real-world APIs, authentication systems, and full-stack applications. Every production Node.js server starts with this same pattern: listen on a port, handle requests, and send responses.

Conclusion

Node.js makes it incredibly simple to run JavaScript outside the browser and build fast, scalable server applications. From installing the runtime and verifying it in the terminal, to experimenting in the REPL, running your first script, and launching a working HTTP server, you have now completed the essential first steps of Node.js development.

Understanding this workflow gives you a clear picture of how backend applications start, how servers listen for requests, and how JavaScript powers both the frontend and the backend. In the next steps, you can explore npm packages, routing, Express.js, and connecting to databases.

Every large-scale Node.js application begins exactly like this, one file, one command, and one running server.

In this blog, we will understand what Express.js is, why it simplifies Node.js development, how to create your first Express server, how to handle GET and POST requests, how to send responses, and how this connects to real browser and API calls.

First, let’s understand what Express.js is and why it exists.

What Express.js is

Express.js is a lightweight, fast, and flexible web framework built on top of Node.js. Think of it as a toolkit that gives you ready-made methods to handle routes, parse requests, and format responses. Instead of writing long, manual code to check URLs, handle HTTP methods, or set headers, Express gives you simple functions like app.get() and app.post().

Express does not replace Node.js. It simply wraps around it and removes the boilerplate. It is unopinionated, meaning it does not force you into a specific project structure or database. You decide how to build your application, and Express provides the routing and middleware foundation to make it work smoothly.

Why Express simplifies Node.js development

When you use raw Node.js to create a server, you have to manually parse request URLs, check HTTP methods, handle query strings, read request bodies, and set response headers. This takes a lot of repetitive code and is prone to errors.

Express removes that friction. It provides:

• Clean, readable routing (/home, /api/users, /login, etc.)

• Built-in middleware support for parsing JSON, handling cookies, and logging requests

• Simple syntax for handling different HTTP methods

• Easy error handling and response formatting

• Seamless integration with template engines and static files

Because of this, developers can focus on building features instead of managing low-level server logic. Express is the bridge between raw Node.js and production-ready web applications.

Creating your first Express server

Let’s start by setting up a basic Express server. First, make sure you have Node.js installed. Then, create a new folder, open your terminal, and run:

npm init -y
npm install express

Now, create a file called index.js and add the following code:

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

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

This code does three simple things:

• Imports the Express module

• Creates an application instance

• Starts listening on port 3000

When you run node index.js, your server is live. But right now, it does not respond to any requests. If you visit http://localhost:3000 in your browser, you will see a loading state or a "Cannot GET /" error. Let’s fix that by adding routes.

Handling GET requests

GET requests are used when a client wants to retrieve data from the server. In Express, handling a GET request is straightforward. Add this to your index.js file:

app.get('/', (req, res) => {
  res.send('Welcome to the home page!');
});

app.get('/user', (req, res) => {
  res.send('User profile page');
});

Here’s what happens behind the scenes:

• app.get() tells Express to listen for GET requests on a specific path

• The first argument is the route (/ or /user)

• The second argument is a callback function with req (request) and res (response)

• When you visit the route in your browser, Express matches the path and sends back the response

GET requests are safe and idempotent. They should only fetch data, not modify anything on the server. Browsers also cache GET requests, which makes them fast for repeated visits.

Handling POST requests

POST requests are used when a client wants to send data to the server, like submitting a form, creating a new account, or uploading information. Unlike GET, POST requests carry a body. To read that body, Express needs a little help. Add this line before your routes:

app.use(express.json());

Now, create a POST route:

app.post('/user', (req, res) => {
  const userData = req.body;
  console.log('Received data:', userData);
  res.send('User created successfully');
});

How this works:

• express.json() is middleware that parses incoming JSON data and attaches it to req.body

• req.body contains the data sent by the client

• The server logs the data and sends a confirmation response

You can test this using tools like Postman or curl:

curl -X POST http://localhost:3000/user -H "Content-Type: application/json" -d '{"name": "Suprabhat", "age": 23}'

POST requests are meant for creating or updating resources. They are not cached by browsers and can carry large payloads. Without the JSON middleware, req.body would be undefined, and your server would not be able to read the incoming data.

Sending responses

Express gives you multiple ways to send responses back to the client. The method you choose depends on what kind of data you are returning and how the frontend expects to receive it.

The most common response methods are:

• res.send(): Sends plain text, HTML, or buffers

• res.json(): Sends JSON data and automatically sets the correct Content-Type header

• res.status(): Sets HTTP status codes before sending a response

• res.sendFile(): Sends static files like images, PDFs, or documents

Here’s a practical example combining status codes and JSON:

app.get('/api/info', (req, res) => {
  res.status(200).json({
    message: 'Success',
    data: { name: 'Suprabhat', age: 23, role: 'Developer' }
  });
});

Why response methods matter:

• They tell the client what happened (success, error, not found, unauthorized)

• They format data correctly so the frontend or API consumer can read it

• They control headers, status codes, and content types

• They prevent broken connections and timeout errors

Without proper responses, the client would not know if a request succeeded or failed. Status codes like 200 (OK), 201 (Created), 400 (Bad Request), and 404 (Not Found) are the universal language of web communication.

Connecting Express routes to real browser and API requests

When you type a URL in your browser, click a button in a web app, or call an API from a frontend framework, the same routing process happens.

Browser/API → Sends HTTP request → Express matches route → Runs callback → Sends response → Client receives data

Every web interaction depends on this request-response cycle. Express simply makes it predictable, readable, and easy to manage. Whether you are building a simple portfolio site, a REST API, or a full-stack application, routing is the backbone that connects users to your server logic.

Conclusion

Express.js is the missing piece that turns raw Node.js into a powerful, developer-friendly web framework. By simplifying routing, handling GET and POST requests cleanly, and providing flexible response methods, Express lets you build servers faster and with less code.

Understanding how routes work gives you a clear picture of how web applications communicate, how data flows between clients and servers, and how modern APIs are structured. Once you master these basics, you are ready to add middleware, connect databases, handle authentication, and build production-ready applications.

In this guide, we’ll break down exactly what makes Node.js fast, demystify concepts like non-blocking I/O, event-driven architecture, and the single-threaded model, explore where Node.js shines in production, and look at real-world companies that trust it to power their platforms. Whether you’re a beginner or transitioning from another backend technology, this post will give you a clear, practical understanding of how Node.js works under the hood.

What Makes Node.js Fast?

When developers say “Node.js is fast,” they rarely mean raw computational speed. Languages like C++ or Rust will always outperform JavaScript in CPU-heavy tasks. Node.js’s speed comes from how it handles concurrency and I/O operations.

Traditional server models (like Apache or early Java servers) often use a multi-threaded approach: each incoming request gets its own thread. While this works for low traffic, threads consume memory and CPU. Under heavy load, thread creation and context switching become bottlenecks.

Node.js takes a completely different approach. Instead of spawning threads for every request, it uses a single-threaded, event-driven, non-blocking I/O model. This allows it to handle tens of thousands of concurrent connections with minimal overhead. Let’s unpack each of these pillars.

The Single-Threaded Model Explained

At first glance, “single-threaded” sounds like a limitation. How can one thread possibly handle multiple users at once?

In Node.js, JavaScript execution runs on a single main thread. This means your code executes line by line, without parallel JS execution. But here’s the catch: Node.js doesn’t use that thread to wait for slow operations like database queries, file reads, or network requests.

Think of it like a skilled receptionist at a busy clinic. Instead of personally performing every medical test (which would take hours), the receptionist logs requests, hands them off to specialists, and continues checking in new patients. When a test is complete, the specialist notifies the receptionist, who then delivers the results.

Under the hood, Node.js uses the V8 JavaScript engine (the same one powering Chrome) to compile JavaScript into highly optimized machine code. The single thread acts as an orchestrator, not a worker. Heavy lifting is delegated to the system via a C++ library called libuv, which manages a background thread pool specifically for I/O tasks.

Non-Blocking I/O: The Secret Sauce

I/O (Input/Output) refers to any operation that interacts with external resources: reading files, querying databases, making HTTP requests, or streaming data. These operations are inherently slow compared to CPU instructions.

In a blocking model, the thread pauses and waits until the I/O operation finishes. Nothing else can happen during that wait time. In a non-blocking model, Node.js initiates the I/O task, immediately moves on to the next line of code, and registers a callback to handle the result later.

Here’s a simplified example:

// Non-blocking database fetch
fetchUserFromDB((err, user) => {
  if (err) return console.error(err);
  console.log(user); // e.g., { name: "Suprabhat", age: 23, }
});

console.log("This runs immediately, without waiting for the DB!");

Notice how the second console.log executes right away. Node.js doesn’t sit idle while the database responds. It continues processing other requests, and when the database returns the data, the callback fires. This non-blocking behavior is what allows Node.js to maintain high throughput under heavy I/O load.

Event-Driven Architecture: How Node.js Stays Responsive

Non-blocking I/O is powerful, but it needs a system to track and manage all those pending operations. That’s where the event-driven architecture and the Event Loop come in.

The Event Loop is a continuously running mechanism that checks for completed asynchronous tasks and executes their associated callbacks. It operates in phases:

1. Timers: Executes setTimeout and setInterval callbacks.

2. Pending Callbacks: Handles I/O callbacks deferred from previous loops.

3. Poll: Retrieves new I/O events and executes their callbacks.

4. Check: Runs setImmediate callbacks.

5. Close: Handles cleanup callbacks (like closing sockets).

Returning to our clinic analogy: the Event Loop is the receptionist’s clipboard. It constantly checks which test results are ready, matches them to the correct patient, and delivers them in order. Because the loop never blocks, Node.js stays responsive even when juggling thousands of pending requests.

Important caveat: The Event Loop can be blocked by CPU-intensive JavaScript code (like complex loops or heavy data processing). If your main thread is stuck calculating, it can’t check the clipboard. That’s why Node.js is optimized for I/O-bound workloads, not CPU-bound ones.

Where Node.js Performs Best

Understanding Node.js’s architecture makes it easy to identify its ideal use cases:

✅ Real-Time Applications: Chat apps, live collaboration tools, and multiplayer games benefit from Node’s low-latency, bidirectional communication (often paired with WebSockets).
✅ APIs & Microservices: Lightweight, fast, and JSON-native, Node.js is perfect for building RESTful or GraphQL APIs that handle high request volumes.
✅ Streaming Applications: Video/audio streaming, file uploads, and data pipelines work smoothly because Node processes data in chunks without buffering everything in memory.
✅ Single Page Applications (SPAs): Serving assets and handling routing for React, Vue, or Angular frontends aligns perfectly with Node’s event-driven model.
✅ High-Concurrency, I/O-Heavy Workloads: Dashboards, notification systems, and proxy servers thrive under Node’s non-blocking architecture.

⛔ Where to Avoid Node.js: CPU-intensive tasks like video encoding, machine learning model training, or complex mathematical simulations. For these, consider offloading to worker threads, external services, or languages better suited for parallel computation.

Real-World Companies Using Node.js

Node.js isn’t just a developer favorite, it’s battle-tested at scale. Here’s how industry leaders leverage it:

🔹 Netflix: Migrated to Node.js to unify their frontend and backend stack, reducing startup time by 70% and enabling faster A/B testing.
🔹 PayPal: Replaced Java with Node.js for their web layer, cutting response times in half and doubling requests per second with fewer servers.
🔹 LinkedIn: Switched their mobile backend to Node.js, reducing server count from 30 to 3 while improving performance and developer velocity.
🔹 Uber: Uses Node.js for its massive real-time dispatch system, handling millions of concurrent connections with minimal latency.
🔹 Walmart: Adopted Node.js to handle Black Friday traffic spikes, successfully managing over 500 million page views without downtime.
🔹 NASA: Utilizes Node.js for data-intensive applications and internal tooling, proving its reliability even in mission-critical environments.

These companies didn’t choose Node.js for raw speed, they chose it for scalability, developer efficiency, and exceptional handling of concurrent I/O operations.

Conclusion

Node.js isn’t fast because it computes faster. It’s fast because it waits smarter. By combining a single-threaded JavaScript execution model, non-blocking I/O, and an event-driven architecture, Node.js eliminates the traditional bottlenecks of server-side programming. It thrives in environments where concurrency, real-time communication, and I/O efficiency matter more than heavy number crunching.

As you begin your Node.js journey, remember: architecture dictates performance. Use it for APIs, real-time apps, and microservices. Offload CPU-heavy tasks. Embrace asynchronous patterns. And most importantly, let the Event Loop do what it does best—keep your application responsive, scalable, and efficient.

Ready to build your first non-blocking server? Start small, experiment with callbacks and promises, and watch how Node.js handles concurrency with elegance. The modern web runs on event-driven systems, and now you understand exactly why.

In this guide, we’ll walk through the complete lifecycle of file uploads in web applications. We’ll explore where files are stored, compare local vs. external storage, learn how to serve them using Express, access them via URLs, and cover essential security practices. By the end, you’ll have a clear, production-aware understanding of how modern apps handle user uploads safely and efficiently.

Where Uploaded Files Are Stored

When a user submits a file through a web form, it doesn’t instantly appear in a permanent folder. Instead, the server receives the file as a continuous stream of bytes. In Node.js environments, middleware like multer or express-fileupload intercepts this stream and temporarily writes it to a system-defined temporary directory (such as /tmp on Linux or %TEMP% on Windows).

This temporary stage is crucial. It ensures that incomplete, interrupted, or malformed uploads don’t pollute your permanent storage. Once the upload finishes successfully, your application logic takes over. You can then validate the file, rename it, and move it to a dedicated permanent directory like uploads/, public/assets/, or storage/images/.

Developers typically store metadata about the file (original name, new name, size, MIME type, and storage path) in a database. This separation of file storage and metadata keeps your system organized and makes it easy to retrieve files later.

Local Storage vs. External Storage Concept

Once you decide where to save files permanently, you face a fundamental architectural choice: local storage or external/cloud storage.

Local Storage

Local storage means saving files directly on your server’s filesystem. It’s straightforward, requires zero external configuration, and works perfectly for learning, prototyping, or small-scale apps.

Pros:

• Fast setup and zero external dependencies

• Low latency for local reads/writes

• Free (uses existing server disk)

Cons:

• Doesn’t scale across multiple servers or containers

• Manual backups and disk management required

• Server migrations become complicated

• Vulnerable to single-point hardware failure

External Storage

External storage refers to cloud object storage services like AWS S3, Google Cloud Storage, Azure Blob, or specialized media platforms like Cloudinary and Uploadcare.

Pros:

• Horizontally scalable and highly available

• Built-in CDN integration for fast global delivery

• Automatic backups, versioning, and lifecycle policies

• Decouples storage from your application servers

Cons:

• Requires API setup and authentication

• Incurs usage-based costs

• Slightly more complex initial implementation

Best Practice: Start with local storage while learning, but design your upload service with an abstraction layer. This makes swapping to cloud storage later as simple as changing a configuration file rather than rewriting your entire codebase.

Serving Static Files in Express

Storing files is only half the equation. Users and browsers need to access them, and Express makes this effortless with its built-in express.static() middleware.

By default, Express does not expose your project directories to the web. This is a security feature. To safely serve uploaded files, you explicitly tell Express which folder should be publicly accessible:

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

// Serve files from the 'uploads' directory under the '/uploads' URL prefix
app.use('/uploads', express.static(path.join(__dirname, 'uploads')));

app.listen(3000, () => console.log('Server running on http://localhost:3000'));

With this configuration, any file saved inside the uploads/ folder becomes publicly accessible. The middleware automatically handles:

• Correct MIME type headers

• Efficient byte-range requests (useful for video/audio streaming)

• Basic caching headers

• Secure path resolution (prevents directory traversal)

Never use express.static() on your entire project root. Always isolate uploaded or public assets in a dedicated folder.

Accessing Uploaded Files via URL

Once static serving is configured, accessing files via URL becomes predictable and straightforward. When a file is uploaded, your backend should generate a safe, unique filename and store the relative path in your database.

For example, if a user with name: "Suprabhat", age: 23, uploads avatar.png, your backend might rename it to user_8f3a2b_avatar.png and save /uploads/user_8f3a2b_avatar.png in the database. Later, when rendering their profile, your frontend simply uses that path:

<img src="/uploads/user_8f3a2b_avatar.png" alt="User Avatar" />

If you migrate to cloud storage, the flow remains identical. Instead of a local path, your database stores the full cloud URL: https://your-bucket.s3.amazonaws.com/user_8f3a2b_avatar.png

Important URL Guidelines:

• Never expose internal server paths or absolute filesystem routes.

• Always serve files through a controlled prefix (/uploads/, /assets/, etc.).

• Avoid dynamic routes that directly map user input to file paths without strict validation.

• Use consistent naming conventions to prevent broken links and cache conflicts.

Security Considerations for Uploads

File uploads are consistently ranked among the top web application vulnerabilities. Without proper safeguards, attackers can upload malicious scripts, overwrite critical files, or exhaust your server’s disk space. Here’s how to lock down your upload pipeline:

1. Validate File Types Properly

Never trust the Content-Type header or file extension alone. Attackers can easily spoof them. Instead, inspect the file’s magic numbers (binary signature) using libraries like file-type or mmmagic. Maintain a strict allowlist (e.g., image/jpeg, image/png, application/pdf).

2. Enforce File Size Limits

Unrestricted uploads can trigger denial-of-service (DoS) attacks. Configure size limits directly in your middleware:

const upload = multer({
  limits: { fileSize: 5 * 1024 * 1024 } // 5MB max
});

3. Sanitize and Rename Filenames

User-provided filenames can contain path traversal sequences like ../../../etc/passwd or executable extensions like .php or .js. Always strip dangerous characters and rename files using UUIDs, timestamps, or cryptographic hashes.

4. Store Uploads Outside Executable Paths

Ensure your server never executes files from the upload directory. Configure your hosting environment or reverse proxy (Nginx/Apache) to treat upload folders as static-only. If possible, store sensitive uploads outside the web root and serve them through authenticated routes.

5. Implement Access Controls

Not all uploads should be public. For private documents or user-specific media, bypass express.static() and serve files through a route that verifies authentication and ownership before streaming the file with res.sendFile().

6. Scan for Malware (Production Grade)

For applications handling sensitive data or public submissions, integrate antivirus scanning using tools like ClamAV or cloud-based scanning APIs before permanently storing or serving files.

Conclusion

Handling file uploads might look simple on the surface, but it requires careful planning around storage architecture, accessibility, and security. Starting with local storage and Express’s static middleware gives you a solid foundation to understand the flow. As your application scales, transitioning to cloud storage and implementing strict validation will keep your system fast, reliable, and secure.

Remember the golden rules: never trust user input, always validate and sanitize, isolate upload directories, and design with both usability and safety in mind. With these practices, you’ll build file-handling features that work seamlessly for everyday users while keeping your infrastructure protected.

Ready to implement your first secure upload route? Spin up a local Express server, configure multer, apply the security checklist above, and watch your application handle files like a production-ready system. Happy coding!

In this blog we will understand what sessions are, what cookies are, what JWT tokens are, how stateful and stateless authentication differ, and when to use each method in real-world projects.

First, let's understand what is authentication and why it exists.

What is authentication and why does it exist

Authentication is how a website recognizes a user after they log in. When a user like name: "Suprabhat", age: 23 signs into an app, the server needs to know that the next request coming from the browser is still from the same person.

Without authentication, every page click would feel like a new visit. No saved cart, no profile page, no personalized content.

So how do we remember users? Three common approaches are used: Cookies, Sessions, and JWT tokens.

Let's understand each one.

What are cookies and when are they used

Cookies are small pieces of data stored in the user's browser. When a user logs in, the server can send a cookie to their browser. The browser then automatically includes that cookie in future requests to the same website.

// Server sets a cookie after login
res.cookie('userId', '12345', { maxAge: 24*60*60*1000 });

Cookies are stored on the client side, automatically sent with requests to the same domain, can have expiration times, and are limited to about 4KB of data.

Think of cookies like a library card. You show it each time you visit, and the librarian recognizes you.

When to use cookies:

• Remembering simple preferences like theme or language

• Storing a session ID or token, not raw user data

• Lightweight login persistence on single-domain sites

What are sessions and why do we need them

Sessions store user data on the server. When a user logs in, the server creates a unique session ID and sends it to the client, usually via a cookie. The client sends this ID back with each request, and the server looks up the ID to find the user's data.

How it works:

1. User logs in, server creates session with sessionId and userId

2. Server sends sessionId to client via cookie

3. Client sends sessionId with each request

4. Server looks up sessionId to find user data

Sessions keep data on the server, the client only holds a simple identifier, they are easy to invalidate by deleting the session, and they require server storage and lookup.

Think of sessions like a coat check. You get a ticket, and the staff keeps your actual coat safe.

When to use sessions:

• Traditional server-rendered apps like Django, Rails, or Express with EJS

• When you need instant logout or permission updates

• Single-domain applications with simple scaling needs

What are JWT tokens and how do they work

JWT, which stands for JSON Web Tokens, are self-contained tokens that encode user information directly inside them. A JWT has three parts: header, payload, and signature. Once issued, the server can verify the token without storing anything.

// Server issues JWT after login
const token = jwt.sign({ userId: 123 }, 'secret', { expiresIn: '1h' });
// Client sends: Authorization: Bearer <token>

JWTs are stateless, meaning no server storage is needed. They contain encoded data, but you should not store secrets in the payload. They are signed to prevent tampering and have built-in expiration via the exp claim.

Think of JWTs like a signed event wristband. The bouncer can verify it is valid just by inspecting the wristband, no list needed.

When to use JWT:

• REST APIs or GraphQL backends

• SPAs like React, Vue, or Angular, or mobile apps

• Microservices or cross-domain authentication

• When horizontal scaling is a priority

What is the difference between stateful and stateless authentication

Comparison table: Sessions vs JWT vs Cookies

Note: Cookies are often used with sessions or JWTs to transport identifiers. They are a delivery method, not a complete auth strategy alone.

When to use each method: real-world decisions

Use Sessions when:

• Building a server-rendered website like an admin panel or blog CMS

• You need immediate access revocation

• Your app runs on one domain

• You are learning and want simpler debugging

Example: An internal tool where name: "Suprabhat", age: 23 manages content. Sessions let you revoke access instantly.

Use JWT when:

• Building a public API or backend for a mobile app

• Your frontend and backend are separate, like SPA plus API

• You need authentication across services or domains

• You want to scale without shared session storage

Example: A fitness app where users log in once and access APIs from phone, web, and watch. JWTs travel easily in headers.

Use simple Cookies when:

• Storing non-sensitive preferences like theme or language

• Lightweight remember me for simple sites

• Transporting a session ID or token, not the data itself

Example: A news site that remembers your preferred category. A simple cookie is enough.

Conclusion

Authentication does not have to be confusing.

Cookies are small data pieces the browser stores and sends automatically. Sessions keep user data on the server and use a cookie to share an ID. JWTs pack user data into a signed token the server can verify without storage.

Choosing between them depends on your project. Need simplicity and control, go with Sessions. Building APIs or mobile apps, choose JWT. Just remembering preferences, simple cookies work.

Your next step: Build a tiny login with sessions. Then rebuild it with JWT. Compare the experience. Hands-on practice beats any tutorial.

Understanding these basics helps you see how the invisible parts of authentication work every time a user logs in.

In this guide, we’ll break down what each type is, how they differ, how to access them in Express, and when to use one over the other. By the end, you’ll know exactly how to structure your routes and handle incoming data with confidence.

What Are URL Parameters?

URL parameters (also called path parameters or route parameters) are dynamic segments embedded directly into the URL path. They act as placeholders for specific values that your application needs to identify a resource.

For example:

/users/42
/posts/javascript-basics
/orders/ORD-9981/items

In these URLs, 42, javascript-basics, and ORD-9981 are URL parameters. They are required for the route to match and typically represent unique identifiers, slugs, or hierarchical relationships. Think of them as the exact "address" of a specific item in your system. If you remove or change a URL parameter, you’re requesting a completely different resource.

What Are Query Parameters?

Query parameters appear after the ? character in a URL and are formatted as key-value pairs. Multiple pairs are separated by &.

For example:

/products?category=electronics&sort=price&limit=10
/users?role=admin&active=true
/search?q=express+tutorial&page=2

Unlike URL parameters, query parameters are optional and do not change the base route. They are primarily used to modify how a resource is retrieved or displayed. Common use cases include filtering, sorting, pagination, search terms, and toggling view modes. The same endpoint can behave differently based on the query string attached to it, making query parameters highly flexible.

Key Differences Between URL and Query Parameters

Understanding these differences helps you design routes that are intuitive, scalable, and aligned with industry standards.

Accessing Params in Express

Express makes working with URL parameters straightforward. You define them in your route path using a colon (:), and Express automatically extracts them into the req.params object.

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

// Define a route with a URL parameter
app.get('/users/:userId', (req, res) => {
  const userId = req.params.userId;
  
  // Mock database response
  const user = {
    id: userId,
    name: "Suprabhat",
    age: 23,
    role: "developer"
  };

  res.json(user);
});

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

When a client requests /users/42, Express matches the route, extracts 42, and assigns it to req.params.userId. You can define multiple parameters in a single route (e.g., /posts/:postId/comments/:commentId), and Express will parse each one into the req.params object.

Note: URL parameters are always returned as strings. If you need numbers or booleans, you must explicitly convert them using parseInt(), Number(), or validation middleware.

Accessing Query Strings in Express

You don’t need to define query parameters in your route path. Express automatically parses everything after the ? and populates the req.query object.

app.get('/products', (req, res) => {
  const { category, sort, limit } = req.query;

  // Default values if query params are missing
  const safeLimit = limit ? parseInt(limit, 10) : 20;
  const safeSort = sort || 'createdAt';

  res.json({
    message: 'Fetching products',
    filters: { category, sort: safeSort, limit: safeLimit }
  });
});

A request to /products?category=books&sort=price&limit=5 will result in:

req.query = {
  category: 'books',
  sort: 'price',
  limit: '5'
}

Express uses the qs library under the hood, which also supports nested objects and arrays (e.g., ?tags=node&tags=express becomes { tags: ['node', 'express'] }). Like URL params, query values are always strings, so type conversion or validation is recommended before using them in database queries or business logic.

When to Use Params vs Query

Choosing between URL parameters and query parameters isn’t just a stylistic preference. It impacts API design, caching, SEO, and developer experience. Follow these practical guidelines:

Use URL Parameters When:

• You’re identifying a specific resource (/users/123, /orders/ORD-55)

• The value is required for the route to make sense

• You’re building RESTful endpoints that follow resource hierarchy

• You want clean, bookmarkable URLs for individual items

• The parameter represents a primary key, slug, or unique identifier

Use Query Parameters When:

• You’re filtering, sorting, or paginating a collection (?status=active&page=2)

• The data is optional or has sensible defaults

• You’re handling search terms (?q=express+routing)

• You need to pass multiple modifiers without creating endless route combinations

• You want to keep your route structure flat and maintainable

Common Mistakes to Avoid:

• Putting optional filters in the path (/users/active/sorted-by-name) → Use query params instead.

• Using query params for required resource IDs (/users?id=42) → Breaks REST conventions and hurts caching.

• Mixing both for the same purpose → Confuses API consumers and complicates documentation.

A good rule of thumb: Path params answer "which one?", query params answer "how should I show it?"

Conclusion

URL parameters and query parameters serve different but complementary roles in web development. URL parameters lock down the identity of a resource, while query parameters give you the flexibility to shape how that resource is delivered. Express handles both elegantly through req.params and req.query, allowing you to build clean, predictable routes without boilerplate parsing logic.

As you design your endpoints, remember to align your choices with REST principles, keep required identifiers in the path, and reserve the query string for optional modifiers. Validate and sanitize all incoming values, convert types explicitly, and document your expected parameters clearly.

With this foundation, you’ll craft APIs that are intuitive for frontend developers, cache-friendly for CDNs, and scalable as your application grows. Spin up an Express server, experiment with different route combinations, and watch how cleanly your app can handle dynamic requests. Happy routing!

But what exactly is middleware? Why does Express rely on it so heavily? And why does the order you write it in matter so much?

In this beginner-friendly guide, we’ll demystify Express middleware, walk through where it fits in the request lifecycle, break down its types, and build real-world examples you can use in your own projects.

What is Middleware in Express?

At its core, middleware is just a function. But it’s a function with special access. Every middleware function receives three arguments:

• req (the incoming request object)

• res (the outgoing response object)

• next (a function that passes control to the next middleware)

Middleware sits between the raw HTTP request and your final route handler. It can:

• Read or modify req and res

• Execute code (like logging or validation)

• End the request-response cycle early (by sending a response)

• Pass control to the next middleware using next()

Think of middleware like a series of security checkpoints at an airport. Your request is the passenger. Each checkpoint inspects, stamps, or redirects the passenger before they finally reach the gate (your route handler).

Where Middleware Sits in the Request Lifecycle

When a request hits your Express server, it doesn’t jump straight to your route logic. Instead, it flows through a middleware pipeline:

1. Request arrives at the server

2. Passes through global/application middleware

3. Passes through router-specific middleware (if matched)

4. Reaches the final route handler

5. Response is sent back to the client

At any point in this chain, a middleware can:

• Modify the request (e.g., parse JSON, attach a user object)

• Reject the request (e.g., return 401 Unauthorized)

• Log data, set headers, or handle errors

• Call next() to continue the journey

If no middleware sends a response and next() is never called, the request will hang until it times out. This is why understanding the flow is critical.

The Role of the next() Function

The next() function is the traffic controller of Express middleware. It tells the server: “I’m done processing. Move to the next function in line.”

Here’s what happens depending on how you use it:

• next() → Moves to the next matching middleware or route

• next(err) → Skips all regular middleware and jumps to error-handling middleware

• Forgetting next() → The request hangs forever (a common beginner bug)

app.use((req, res, next) => {
  console.log("Request received!");
  next(); // Without this, the browser will spin indefinitely
});

next() is what makes middleware composable. You can chain dozens of functions together, and Express will execute them in order, as long as each one calls next().

Why Execution Order Matters

Middleware runs exactly in the order you define it. This isn’t a suggestion; it’s the architecture.

If you place authentication middleware before express.json(), your auth logic might try to read req.body before it’s parsed, resulting in undefined. If you place a catch-all route before your API routes, those API routes will never be reached.

// ✅ Correct order
app.use(express.json());           // Parse body first
app.use(authMiddleware);           // Then check auth
app.get("/dashboard", handler);    // Finally handle route

// ❌ Broken order
app.use(authMiddleware);           // Tries to read unparsed body
app.use(express.json());           // Too late

Always arrange middleware from broad to specific, and from data preparation to business logic.

Types of Middleware in Express

Express categorizes middleware based on where and how it’s applied. Here are the three main types you’ll use daily:

1. Application-Level Middleware

Bound to the entire app instance using app.use() or app.METHOD(). Runs on every request (or a specific path if provided).

app.use((req, res, next) => {
  console.log(`\({req.method} \){req.url}`);
  next();
});

2. Router-Level Middleware

Works exactly like application-level middleware, but is bound to an instance of express.Router(). Ideal for modularizing features.

const router = express.Router();

router.use((req, res, next) => {
  console.log("Router middleware triggered");
  next();
});

router.get("/users", (req, res) => res.send("User list"));
app.use("/api", router);

3. Built-In Middleware

Express ships with a few essential middleware functions out of the box:

• express.json() → Parses incoming JSON payloads

• express.urlencoded({ extended: true }) → Parses form data

• express.static("public") → Serves static files like CSS, images, or JS

You don’t need to install anything extra. Just plug them in at the top of your server file.

Real-World Middleware Examples

Theory is great, but middleware shines in practice. Here are three production-ready patterns you’ll use constantly.

1. Request Logging

Track every incoming request for debugging or analytics.

app.use((req, res, next) => {
  const timestamp = new Date().toISOString();
  console.log(`[\({timestamp}] \){req.method} ${req.url}`);
  next();
});

2. Authentication Guard

Protect routes by verifying a token before allowing access.

const authMiddleware = (req, res, next) => {
  const token = req.headers.authorization;

  if (!token) {
    return res.status(401).json({ error: "No token provided" });
  }

  // In real apps, verify JWT or session here
  req.user = { name: "Suprabhat", age: 23, role: "admin" };
  next();
};

app.get("/profile", authMiddleware, (req, res) => {
  res.json({ message: `Welcome, ${req.user.name}` });
});

3. Request Validation

Ensure required fields exist before hitting your database.

const validateUser = (req, res, next) => {
  const { name, email } = req.body;

  if (!name || !email) {
    return res.status(400).json({ error: "Name and email are required" });
  }

  next();
};

app.post("/register", express.json(), validateUser, (req, res) => {
  res.status(201).json({ message: "User registered successfully" });
});

Notice how each middleware does one thing well, then passes control forward. That’s the Express philosophy.

Conclusion

Middleware is the backbone of Express. It’s how you parse data, secure routes, log activity, handle errors, and structure your backend without cluttering your route handlers. Once you understand the request pipeline, the power of next(), and why order matters, you’ll stop fighting Express and start leveraging it.

Start small. Write a logger. Add a validation check. Experiment with moving middleware up and down your file to see how the flow changes. The more you play with the pipeline, the more intuitive it becomes.

Express doesn’t force a rigid architecture. It gives you a flexible, composable system where every function has a clear job. Middleware is that system in action.

Why Async Code Exists in Node.js

Node.js is built on a single-threaded event loop. This means it can only execute one instruction at a time. At first glance, this sounds limiting. But the internet is full of slow operations: reading files, querying databases, making external API calls, or waiting for user input. If Node.js waited for each of these to finish before moving to the next line, the entire application would freeze. This is called blocking.

To solve this, Node.js uses asynchronous execution. Instead of waiting, it starts a slow operation, registers a function to run when the operation finishes, and immediately moves to the next task. When the slow operation completes, the event loop picks up the registered function and executes it. This keeps the application fast and responsive, even under heavy load.

Think of it like ordering food at a busy café. You don’t stand at the counter waiting for your meal. You get a receipt with an order number, step aside, and maybe check your phone. When your food is ready, you are called to pick it up. Async code works the same way: start the task, step aside, and get notified when it’s done.

Callback-Based Async Execution

In the early days of Node.js, asynchronous operations relied heavily on callbacks. A callback is simply a function passed as an argument to another function, which gets executed later when a task finishes.

Consider a basic file-reading example:

const fs = require('fs');

fs.readFile('data.txt', 'utf8', (err, data) => {
  if (err) {
    console.error('Failed to read file:', err);
    return;
  }
  console.log('File content:', data);
});

console.log('This message prints first!');

Here, readFile starts reading the file in the background. The callback (err, data) => { ... } waits in line. Meanwhile, console.log('This message prints first!') executes immediately. When the file finishes reading, the event loop triggers the callback. This pattern keeps Node.js non-blocking and highly efficient for I/O-heavy applications.

Problems with Nested Callbacks

Callbacks work well for one or two operations. But real-world applications often require multiple sequential steps. You might need to read a configuration file, then query a database, then format the result, and finally send a response. When you chain callbacks inside callbacks, code quickly becomes difficult to read and maintain. Developers call this “Callback Hell” or the “Pyramid of Doom.”

fs.readFile('config.json', 'utf8', (err, config) => {
  if (err) return console.error(err);
  db.connect(config.dbUrl, (err, client) => {
    if (err) return console.error(err);
    client.query('SELECT * FROM users', (err, users) => {
      if (err) return console.error(err);
      console.log('Fetched users:', users);
    });
  });
});

This structure introduces several serious problems:

• Readability drops quickly: The code shifts to the right with every new step, breaking natural reading flow.

• Error handling is repetitive: Every callback needs its own if (err) block, violating the DRY (Don’t Repeat Yourself) principle.

• State management gets messy: Variables from outer scopes must be manually passed down or scoped carefully.

• Debugging becomes painful: Stack traces grow long, and tracking where an error originated takes extra effort.

Imagine a junior developer, name: "Suprabhat", age: 23, trying to maintain a feature built this way. Adding a new step or fixing a bug requires untangling the pyramid, which slows down development and increases the chance of introducing new errors.

Promise-Based Async Handling

Promises were introduced to solve callback hell. A promise is an object that represents the eventual completion (or failure) of an asynchronous operation. Instead of passing a callback, a function returns a promise. You attach handlers to that promise using .then() for success and .catch() for errors.

A promise exists in one of three states:

• Pending: The operation is still running.

• Fulfilled: The operation completed successfully.

• Rejected: The operation failed with an error.

Let’s rewrite the previous example using promises:

const fs = require('fs').promises;

fs.readFile('config.json', 'utf8')
  .then(config => db.connect(config.dbUrl))
  .then(client => client.query('SELECT * FROM users'))
  .then(users => console.log('Fetched users:', users))
  .catch(err => console.error('Something failed:', err));

Notice how the flow is flatter and more readable. Each .then() receives the result of the previous step and passes its own result forward. Errors automatically bubble down to a single .catch(), eliminating repetitive error checks.

Benefits of Promises

Moving from callbacks to promises brings several practical advantages that directly impact developer productivity and code quality:

• Cleaner, linear code: No more rightward drift. Code flows top-to-bottom, matching how we naturally read and reason about logic.

• Centralized error handling: One .catch() at the end handles errors from any step in the chain. You no longer need scattered if (err) blocks.

• Better composability: Promises can be combined using Promise.all(), Promise.race(), or Promise.allSettled(). This makes running parallel tasks straightforward and predictable.

• Foundation for modern syntax: Promises paved the way for async and await. Under the hood, await is simply pausing execution until a promise settles, letting you write asynchronous code that looks synchronous.

• Predictable execution order: Promises guarantee that .then() callbacks run in the order they are attached, avoiding race conditions that often plague callback-heavy code.

For teams, this translates to faster feature development, easier code reviews, and more reliable production systems.

Conclusion

Asynchronous programming is the backbone of Node.js. It exists because modern applications spend most of their time waiting for external I/O, not performing heavy computations. Callbacks were the first solution, but nested callbacks quickly became unmanageable as applications grew. Promises solved this by introducing a structured, chainable way to handle async operations, with cleaner syntax and centralized error handling. Understanding this evolution is crucial for any Node.js developer. Once you master promises, you will find that modern features like async/await become second nature. The next time you build an API, read a database, or call an external service, remember: you are not just writing code, you are orchestrating time. Keep experimenting, chain those promises, and let the event loop do its work efficiently.

The Single-Threaded Nature of Node.js

Unlike traditional web servers like Apache or Java-based servers, which spawn a new thread for every incoming request, Node.js runs its main execution logic on a single thread. This might sound restrictive, but it is actually a deliberate design choice. Threads consume significant memory and require constant context switching by the CPU, which can slow down a server under heavy load. By sticking to one main thread, Node.js keeps memory usage remarkably low and avoids the overhead of managing dozens or hundreds of parallel threads.

However, “single-threaded” does not mean “single-tasking” or “blocking.” Node.js is explicitly designed to never stall that main thread. Instead of waiting for a database query, file read, or network call to finish, it registers a callback and immediately moves on to the next task. When the external operation completes, the result is queued for execution. This non-blocking behavior is what makes Node.js feel like it is doing many things at once, even though only one line of your JavaScript code runs at any given moment.

The Event Loop’s Role in Concurrency

The magic behind Node.js concurrency is the event loop. Think of it as a continuous traffic controller that never sleeps. When your application starts, the event loop begins running in the background. Its job is simple but powerful: continuously check if there are any pending callbacks, execute them in order, and repeat.

The event loop operates in distinct phases, each responsible for handling different types of tasks like timers, I/O callbacks, idle checks, and immediate execution. When you make an asynchronous call, like fetching data from an external API or querying a database, Node.js hands that request off to the underlying operating system or background workers. Your main thread immediately continues executing the next lines of code. Once the external operation finishes, the result is placed in a callback queue. The event loop picks it up during the appropriate phase and executes your registered function.

This model allows Node.js to manage thousands of concurrent connections without creating a dedicated thread for each one. As long as your JavaScript callbacks execute quickly and avoid heavy synchronous computations, the event loop stays highly responsive, and your server remains fast under pressure.

Delegating Tasks to Background Workers

While JavaScript itself runs on a single main thread, Node.js is not entirely working alone. Under the hood, it relies on libuv, a powerful C library that handles asynchronous I/O operations across different operating systems. libuv maintains a thread pool (typically four threads by default) to offload tasks that cannot be handled purely by the OS’s non-blocking APIs.

These delegated tasks include file system operations, DNS resolution, compression, and cryptographic functions. When you call fs.readFile() or use the crypto module, Node.js routes the work to the libuv thread pool. The main thread continues running your application logic, and once the background thread finishes, it notifies the event loop. For even heavier JavaScript workloads, Node.js provides the Worker Threads module, which lets you run CPU-intensive JavaScript code in true parallel threads without blocking the main event loop. This layered delegation ensures that long-running tasks do not choke your application’s responsiveness.

Handling Multiple Client Requests

Let’s see how this architecture works in a real-world scenario. Imagine a user with name: "Suprabhat", age: 23, visits your e-commerce platform. At the exact same moment, hundreds of other users are browsing products, adding items to carts, and checking out. In a traditional multi-threaded server, each request might consume a dedicated thread, quickly exhausting memory and CPU resources. In Node.js, the main thread accepts each connection, registers the required asynchronous operations (like database reads or external payment API calls), and immediately returns control to the event loop.

While Suprabhat’s request waits for a database response, Node.js is already processing the next user’s request. When the database finally replies, the event loop queues the callback, executes it, formats the JSON response, and sends it back to Suprabhat’s browser. This cycle repeats continuously. Because I/O operations are handled asynchronously and delegated to the OS or background threads, the main thread spends almost all its time accepting new connections and processing ready callbacks, not idly waiting.

Why Node.js Scales Well

Node.js scales exceptionally well for I/O-bound applications, which cover the vast majority of modern web APIs, real-time dashboards, and microservices. Its low memory footprint means you can run many instances on a single server or distribute them across a containerized cluster. Tools like PM2 or the built-in cluster module allow you to fork the single-threaded process across multiple CPU cores, effectively multiplying your server’s capacity without rewriting your application code.

The event-driven architecture also aligns perfectly with modern cloud infrastructure. Load balancers can distribute incoming TCP/HTTP traffic across multiple Node.js instances, and because each instance handles thousands of concurrent connections efficiently, horizontal scaling becomes straightforward and cost-effective. While Node.js is not ideal for heavy CPU-bound tasks like video encoding or complex mathematical simulations (unless you explicitly use Worker Threads or offload to specialized services), it shines in real-time applications, REST/GraphQL APIs, streaming platforms, and collaborative tools.

Conclusion

Node.js proves that high concurrency does not require multi-threaded complexity. By combining a single-threaded event loop, non-blocking I/O, and intelligent background delegation, it delivers remarkable performance and predictable scalability. Understanding how the event loop orchestrates requests and how tasks are offloaded behind the scenes empowers you to write efficient, production-ready applications. As you continue building with Node.js, keep the event loop in mind, avoid blocking synchronous calls, and leverage background workers when heavy lifting is required. The result? Fast, scalable, and resilient applications that handle real-world traffic with ease.

Then came Node.js, and everything changed.

Today, JavaScript powers everything from frontend interfaces to backend APIs, real-time chat apps, and even command-line tools. But how did a browser scripting language suddenly run on servers? What makes Node.js different? And why do companies like Netflix, Uber, and LinkedIn rely on it?

In this beginner-friendly guide, we’ll break down exactly what Node.js is, why JavaScript was originally trapped in the browser, how Node.js set it free, and the core ideas that make it so powerful.

What Exactly is Node.js?

Let’s clear up a common misconception right away: Node.js is not a programming language, and it’s not a framework.

Node.js is a runtime environment. In simple terms, it’s a platform that allows JavaScript code to run outside of a web browser. It provides the necessary tools, libraries, and system access so JavaScript can interact with your computer’s operating system, read files, open network ports, and handle server requests.

Think of it like an engine stand. JavaScript is the engine, and Node.js is the stand that lets you run that engine in a garage instead of inside a car.

Why JavaScript Was Originally Browser-Only

JavaScript was created in 1995 by Brendan Eich at Netscape with a very specific goal: make web pages interactive. It was designed to run inside browsers, and for security reasons, browsers intentionally sandboxed it.

This sandbox meant JavaScript could:

• Manipulate HTML and CSS

• Respond to user clicks and keyboard input

• Make limited network requests (later via AJAX)

But it could not:

• Read or write files on your computer

• Open raw network sockets

• Access system processes or hardware

• Run independently without a browser tab open

These restrictions were necessary. Imagine if any website you visited could silently read your documents or execute system commands. The browser sandbox kept users safe, but it also locked JavaScript into the client side.

How Node.js Made JavaScript Run on Servers

In 2009, a developer named Ryan Dahl asked a simple but revolutionary question: What if we took JavaScript out of the browser and gave it access to the system?

He didn’t rewrite JavaScript. Instead, he took Google’s V8 JavaScript engine (the same one powering Chrome), extracted it from the browser, and wrapped it with C++ bindings. These bindings acted as a bridge, exposing operating-system-level features like:

• File system access (fs module)

• Networking and HTTP servers (net, http modules)

• Process management and environment variables

• Cryptography and streams

Suddenly, JavaScript wasn’t just manipulating DOM elements anymore. It could listen on port 3000, read a database, serve JSON, and handle thousands of concurrent requests. Node.js was born, and JavaScript became a full-stack language.

The V8 Engine: A High-Level Overview

You’ll often hear that Node.js is “fast,” and much of that credit goes to the V8 engine.

V8 is an open-source JavaScript engine written in C++ and developed by Google. Traditionally, scripting languages were interpreted line-by-line, which made them slow. V8 changed that by using Just-In-Time (JIT) compilation. Instead of reading JavaScript slowly during execution, V8 compiles it directly into optimized machine code that your CPU can run natively.

At a high level, V8:

• Parses your JavaScript code

• Compiles it into fast machine code before/during execution

• Optimizes hot code paths automatically

• Handles memory management and garbage collection

Node.js simply leverages V8’s speed and pairs it with system-level APIs. You write JavaScript, V8 makes it run fast, and Node.js gives it server capabilities.

Event-Driven Architecture & Non-Blocking I/O

If V8 is the muscle, event-driven architecture is the nervous system of Node.js. This is where beginners often get confused, so let’s simplify it.

Traditional server languages often use a thread-per-request model. If 100 users make a request, the server spins up 100 threads. If one request waits for a database query, that thread sits idle, wasting memory and CPU.

Node.js works differently. It runs on a single thread but uses an event loop to handle tasks asynchronously. Here’s a real-world analogy:

Imagine a restaurant with one highly efficient waiter (the event loop). Instead of standing in the kitchen waiting for each dish to cook (blocking), the waiter takes an order, sends it to the kitchen, and immediately goes to serve other tables. When the food is ready, the kitchen rings a bell (an event), and the waiter delivers it. No waiting. No idle time.

In technical terms:

• I/O operations (database calls, file reads, network requests) are handed off to the system

• Node.js continues executing other code

• When the operation finishes, a callback or promise resolves, and the event loop picks it up

• This is called non-blocking I/O

This architecture allows Node.js to handle tens of thousands of concurrent connections with minimal overhead, making it incredibly efficient for I/O-heavy workloads.

Real-World Use Cases of Node.js

Node.js isn’t a magic bullet for every problem, but it shines in specific scenarios. Here’s where it’s commonly used in production:

1. Real-Time Applications

Chat apps, live dashboards, collaborative editors (like Google Docs), and multiplayer games benefit from Node’s event-driven model. Technologies like WebSockets integrate seamlessly, enabling instant two-way communication.

2. RESTful APIs & Microservices

Because JavaScript natively handles JSON, Node.js is a natural fit for building lightweight, fast APIs. Frameworks like Express.js make routing, middleware, and request handling straightforward. Many companies split monolithic apps into Node-powered microservices.

3. Streaming Applications

Node.js handles data streams efficiently. Instead of loading an entire file into memory, it processes data in chunks. This makes it ideal for video/audio streaming, large file uploads, and real-time data pipelines.

4. Developer Tools & CLI Utilities

The npm (Node Package Manager) ecosystem hosts over a million packages. Tools like Webpack, ESLint, Vite, and countless CLI utilities are built with Node.js because it’s cross-platform, fast, and easy to distribute.

5. Server-Side Rendering (SSR) & Full-Stack Frameworks

Modern frameworks like Next.js, Nuxt, and Remix use Node.js to render React/Vue components on the server, improving SEO and initial load performance before hydrating on the client.

Where Node.js Isn’t Ideal

It’s worth noting that Node.js struggles with CPU-intensive tasks like video encoding, image processing, or complex mathematical computations. Since it runs on a single thread, heavy CPU work can block the event loop. For those cases, languages like Python, Go, or Rust, or offloading to worker threads, are better choices.

Conclusion

Node.js didn’t just change where JavaScript could run; it changed how developers think about building web applications. By extracting the V8 engine from the browser, bridging it to system APIs, and embracing an event-driven, non-blocking architecture, Node.js turned a client-side scripting language into a server-side powerhouse.

If you’re just starting out, don’t worry about mastering every concept at once. Begin by running a simple node app.js, create a basic HTTP server, and watch how JavaScript behaves outside the browser. The more you experiment, the clearer the event loop, modules, and async patterns will become.

JavaScript was once confined to making buttons click. Today, thanks to Node.js, it powers APIs, real-time systems, and full-stack applications across the globe. And the best part? You already know the language. You just need the runtime.

In this blog, we will step into the shoes of a system investigator. We will understand how Linux actually works under the hood by exploring its file system structure. We will dive into where user data lives, how the system talks to hardware, where DNS configurations hide, and how processes are managed.

First, let’s understand the central brain of the configuration: the /etc directory.

1. The System’s Rulebook: /etc/passwd and /etc/shadow

What it does: The /etc directory holds all the global configuration files for your system. Inside it, /etc/passwd lists all the registered users on the system, while /etc/shadow securely stores their encrypted passwords.

Why it exists: Linux is a multi-user system. Imagine we want to create an account for a new developer, let's say, name: "Suprabhat", age: 23. Linux needs a centralized way to remember Suprabhat’s user ID, his default shell (like bash), and his home directory.

What problem it solves: Without these files, the operating system wouldn’t know who is allowed to log in, what privileges they have, or where their files should be saved. It solves the problem of identity management.

Interesting Insight: If you open /etc/passwd, you won't actually find any passwords! Years ago, passwords used to be stored there in plain sight. For security, Linux developers moved the passwords to /etc/shadow, which can only be read by the root user (the super admin). /etc/passwd remains readable by everyone so applications know who exists on the system, but the actual security key is hidden away.

2. The Illusion of Files: /proc (The Process Information Pseudo-file System)

What it does: The /proc directory contains directories and files that act as a window into the core of the Linux kernel and running processes. For example, /proc/cpuinfo shows details about your processor, and /proc/meminfo shows your RAM usage.

Why it exists: When you open a Task Manager on Windows, it shows you running apps. In Linux, the system needs a way to expose what the CPU and memory are doing in real-time without requiring complex programming.

What problem it solves: It bridges the gap between the kernel (the core of the OS) and user applications. It allows tools to monitor system health simply by reading text files.

Interesting Insight: /proc is completely fake! It is a "pseudo-file system." It doesn’t exist on your hard drive at all. It is generated dynamically in your RAM by the kernel. When you read a file inside /proc, you are actually querying the kernel directly at that exact millisecond. If you reboot, /proc is completely wiped and rebuilt.

3. Where Hardware Meets Software: The /dev Directory

What it does: This directory contains "device files." Every piece of hardware attached to your computer, your hard disk (/dev/sda), your webcam (/dev/video0), or your mouse, has a corresponding file here.

Why it exists: Linux applications don’t want to write complicated code to talk to different brands of hard drives or webcams. By turning hardware into files, Linux makes life easy for developers.

What problem it solves: It standardizes hardware interaction. To send data to a device, a program just "writes" to that device's file. To read from a microphone, a program just "reads" from the microphone's file.

Interesting Insight: There is a famous file here called /dev/null. It is the system's "black hole." If you have a program that generates a lot of annoying error messages and you want to silence them, you can route the output to /dev/null. Anything sent there is instantly destroyed and discarded.

4. The Internet’s Compass: /etc/resolv.conf

What it does: This file tells your Linux system which DNS (Domain Name System) servers to use when converting human-readable websites (like google.com) into computer-readable IP addresses.

Why it exists: When you open a web browser and type a URL, your computer has to ask someone, "Where is this website?" /etc/resolv.conf contains the IP addresses of the servers it should ask.

What problem it solves: It provides the system with a critical roadmap for internet navigation. Without it, your system wouldn't know how to resolve domain names, and the internet would seem completely broken unless you memorized IP addresses.

Interesting Insight: If you manually edit this file to add a fast DNS server (like Google's 8.8.8.8), you might be surprised to find your changes erased after a reboot! This is because modern Linux systems use background services (like NetworkManager or systemd-resolved) that automatically overwrite /etc/resolv.conf based on the network you just connected to (like a coffee shop Wi-Fi).

5. The System’s Diary: /var/log

What it does: The /var/log directory is where Linux keeps its journals. Every time someone logs in, every time a web server crashes, and every time the system boots up, a note is written here.

Why it exists: Computers do millions of things in the background. If something goes wrong, administrators need a paper trail to figure out what happened.

What problem it solves: It solves the problem of blind troubleshooting. Instead of guessing why a server crashed at 3:00 AM, you can read the logs to see exactly what happened at 2:59 AM.

Interesting Insight: If you manage a public-facing Linux server and look inside /var/log/auth.log (or /var/log/secure depending on your Linux version), you will likely see hundreds of failed login attempts from unknown IP addresses all over the world. These are automated bots trying to guess your passwords. Seeing this in real-time is a powerful reminder of why we use strong passwords and SSH keys!

6. The Heartbeat of Background Tasks: /etc/systemd/system/

What it does: This directory contains configuration files (called "unit files") that dictate how background services, like web servers, databases, or network managers, should start, stop, and behave.

Why it exists: When you turn on your computer, you don’t want to manually type commands to start your database, your web server, and your firewall. You want them to start automatically.

What problem it solves: It provides a structured, automated way to manage the lifecycle of software. If a web server crashes, systemd can look at its configuration file here and know exactly how to restart it automatically.

Interesting Insight: You can create your own custom service in minutes. If you write a simple Python script and want it to run forever in the background, you just create a .service file here, tell systemd where your script is, and Linux will treat your script with the same respect and priority as enterprise-level databases!

Conclusion

Linux is not a black box; it is an open book if you know which pages to turn. By exploring directories like /etc for configurations, /proc for active memory state, /dev for hardware, and /var/log for history, you move from being just a "user" to a true system investigator.

Understanding this file structure helps you see exactly how data is managed, how security is enforced, and how the operating system talks to the physical machine behind the scenes. The next time you are on a Linux terminal, don't just stay in your home folder, take a walk through the root directory and see what secrets you can uncover!

For years, Arrays and Objects were the only tools developers had to organize data. But as web applications became more complex, developers started running into frustrating limitations.

To solve these problems, JavaScript introduced two powerful new data structures in ES6: Map and Set.

In this blog, we will explore the problems with traditional Objects and Arrays, what Map and Set are, how they differ from their older counterparts, and exactly when you should use them in your own code.

The Problem with Traditional Objects and Arrays

Before we look at the solutions, we need to understand the problems.

The Array Problem: Arrays are fantastic for keeping a list of items in a specific order. However, arrays allow duplicate values. If you are building a social media app and want to keep a list of unique users who liked a post, an Array will happily let the same user be added 10 times. To prevent this, you have to write extra loops and conditional logic to check if a user already exists before adding them.

The Object Problem: Objects are the traditional way to store key-value data, like a user profile where name: "Suprabhat", age: 23. But Objects have a massive hidden flaw: Object keys can only be Strings or Symbols. If you try to use a number, a boolean, or even another object as a key, JavaScript will automatically convert it into a string. This can cause bizarre bugs and limits how you can organize complex data.

Let's see how Map and Set rescue us from these issues.

What is a Set?

A Set is a special type of collection that holds a list of values, just like an Array. But it has one strict, magical rule: Every value in a Set must be 100% unique.

You can never have duplicates in a Set. If you try to add a value that already exists, the Set simply ignores it. This "uniqueness property" makes Sets incredibly useful for filtering data.

Let's look at how easy it is to use a Set:

// Creating a new Set
const uniqueTags = new Set();

// Adding values
uniqueTags.add("javascript");
uniqueTags.add("web");
uniqueTags.add("javascript"); // This is a duplicate!

console.log(uniqueTags); 
// Output: Set(2) { 'javascript', 'web' }

Notice how we tried to add "javascript" twice, but the Set only kept one copy.

A very common developer trick is to pass an Array with duplicates directly into a Set to instantly clean it up:

const messyArray = [1, 2, 2, 3, 3, 3, 4];
const cleanSet = new Set(messyArray);

console.log(cleanSet); // Output: Set(4) { 1, 2, 3, 4 }

Difference between Set and Array

While they look similar, they serve very different purposes.

What is a Map?

A Map is a collection of keyed data items, just like an Object. It holds key-value pairs.

However, Map completely solves the biggest problem with Objects: A Map allows keys of ANY data type. Your key can be a string, a number, a boolean, a function, or even an entire object!

Let's look at an example. Imagine we want to store extra information about a specific user object without actually modifying the original object.

// Our traditional user object
const user1 = { name: "Suprabhat", age: 23 };

// Creating a new Map
const userRoles = new Map();

// We are using the ENTIRE user object as the key!
userRoles.set(user1, "Admin");

console.log(userRoles.get(user1)); // Output: "Admin"

If we tried to do this with a regular Object, JavaScript would convert the user1 object into a useless string "[object Object]". With Map, the original object is preserved securely as the key.

Additionally, Maps have built-in features that make them easier to work with, such as a .size property that instantly tells you how many items are inside (unlike Objects, where you have to manually count the keys).

Difference between Map and Object

Here is a quick comparison to help you choose the right tool for key-value storage.

When to use Map and Set

Now that we know how they work, when should you actually use them in your daily coding?

When to use Set:

• Removing Duplicates: Whenever you receive messy data (like user inputs or database results) and need to ensure there are no repeating values.

• Fast Lookups: If you have a massive list of ID numbers and you need to constantly check if a specific ID exists, using mySet.has(id) is much faster than searching through an Array.

• Managing States: Keeping track of things that are either "on" or "off" (like a list of currently selected checkboxes).

When to use Map:

• Complex Keys: When you need to associate data with a DOM element or another Object without modifying the original object.

• Frequent Updates: Maps are highly optimized for scenarios where you are constantly adding and removing key-value pairs.

• Predictable Iteration: When you need to loop through key-value data and absolutely need the items to appear in the exact order you added them.

Conclusion

Arrays and Objects will always be the foundational building blocks of JavaScript. You will still use them every single day.

However, Map and Set are highly specialized tools built for modern development. By understanding that Set is your go-to for guaranteed unique lists, and Map is your heavy-duty key-value storage that accepts any data type, you will write cleaner, faster, and much less buggy code.

That receipt is not your food, but it is a promise that you will get your food in the future. While you wait, you don't have to freeze in place; you can go fill your drink, find a table, or talk to your friends. Eventually, your number is called, and you either get your delicious burger, or the cashier apologizes and says they ran out of ingredients.

In JavaScript, we deal with things that take time, like fetching user data from a server or downloading an image. To handle these time-consuming tasks without freezing the entire website, JavaScript uses exactly this concept: Promises.

In this blog, we will understand what problem promises solve, what a promise actually is, the three states of a promise's lifecycle, how to handle success and failure, and how promise chaining makes our code incredibly easy to read.

First, let’s understand the mess we used to live in before Promises existed.

The Problem Promises Solve

Before promises were introduced, JavaScript handled time-consuming tasks using callbacks. A callback is simply a function passed into another function, designed to run only when the task is finished.

For one simple task, a callback is fine. But what if you have a sequence of tasks that depend on each other?

1. Fetch the user's profile.

2. Using that profile, fetch their recent posts.

3. Using the posts, fetch the comments.

Using callbacks, your code would look like this:

getUserProfile(function(profile) {
    getRecentPosts(profile.id, function(posts) {
        getComments(posts[0].id, function(comments) {
            displayComments(comments);
        });
    });
});

Developers affectionately call this "Callback Hell" or the "Pyramid of Doom." The code keeps moving further and further to the right. It becomes incredibly difficult to read, nearly impossible to debug, and handling errors (like a network failure at step 2) turns into an absolute nightmare.

Promises were created to solve this exact problem. They flatten out the code, vastly improving readability and making error handling a breeze.

What is a Promise? (The Lifecycle and States)

Conceptually, a Promise in JavaScript is exactly like your restaurant receipt. It is an object that represents a future value, a value that is not available right now, but will be resolved at some point later.

Every promise goes through a strict lifecycle and will always be in one of these three states:

1. Pending: This is the initial state. The order has been placed, but the burger is not ready yet. The promise is waiting for the background task to finish.

2. Fulfilled (Resolved): The task completed successfully. Your number was called, and you got your burger. The promise now holds the final data you requested.

3. Rejected: The task failed. The restaurant ran out of ingredients, or your internet disconnected. The promise now holds an error message explaining what went wrong.

Once a promise becomes Fulfilled or Rejected, we say it is "settled." A settled promise can never change its state again.

Handling Success and Failure

When a JavaScript function gives you a promise, you need a way to say: "When this is finally ready, do this. If it fails, do that."

We handle this using two built-in methods: .then() and .catch().

• .then() runs only if the promise is Fulfilled.

• .catch() runs only if the promise is Rejected.

Let's look at how we would handle our restaurant order in code:

orderBurger()
    .then(function(myBurger) {
        // This runs if the promise is FULFILLED
        console.log("Yum! I am eating my " + myBurger);
    })
    .catch(function(errorMsg) {
        // This runs if the promise is REJECTED
        console.log("Oh no: " + errorMsg);
    });

It reads almost exactly like plain English. Order the burger, then eat it, or catch the error. You don't have to pass complex functions deep inside other functions anymore.

The Promise Chaining Concept

The true superpower of promises is Chaining.

Remember the dreadful Callback Hell we looked at earlier? Because every .then() method actually returns a brand new promise, we can chain multiple .then() blocks together. This completely eliminates the Pyramid of Doom.

Let's rewrite that ugly callback code using promise chaining:

getUserProfile()
    .then(function(profile) {
        return getRecentPosts(profile.id);
    })
    .then(function(posts) {
        return getComments(posts[0].id);
    })
    .then(function(comments) {
        displayComments(comments);
    })
    .catch(function(error) {
        console.log("Something went wrong at one of the steps: " + error);
    });

Look at how beautifully this code flows! Instead of moving diagonally to the right, it reads perfectly from top to bottom.

Even better, we only need one single .catch() at the very bottom. If getUserProfile fails, or getRecentPosts fails, or getComments fails, JavaScript will automatically skip the remaining .then() blocks and jump straight down to the .catch(). This makes error handling incredibly clean and centralized.

Conclusion

Promises modernized the way developers write JavaScript. By treating asynchronous operations as a "future value" rather than a messy web of callbacks, our code becomes much more predictable.

Understanding the three states, pending, fulfilled, and rejected, gives you a mental model for how data flows over time. And by mastering .then() and .catch() chains, you can write complex, multi-step network requests that are as easy to read as a simple list of instructions.

The next time you write a network request, remember the restaurant receipt: you are just waiting for a promise to settle!

But the truth is, this is not actively trying to trick you. It just follows a very strict set of rules.

In this blog, we are going to decode those rules. We will explore what this actually represents, how it behaves in the global scope, inside objects, and inside regular functions. Most importantly, we will learn the golden rule for figuring out exactly what this is pointing to in any situation.

Let’s start with the most basic question.

What this Represents

To understand this in JavaScript, think about how we use pronouns in the English language.

Imagine reading this sentence: "Suprabhat bought a new laptop, and he loves it." You immediately know that "he" refers to Suprabhat. You don't need to repeat his name.

In JavaScript, this is exactly like that pronoun. It is a shortcut reference to an object. But which object?

Here is the ultimate secret to understanding this: this is simply the object that is calling the function right now. It does not matter where the function was written, or when it was created. The only thing that matters is how and who is executing the function at the exact moment it runs.

this in the Global Context

Let's start by looking at this completely on its own, outside of any functions or custom objects.

If you open your browser's developer console and simply type:

console.log(this);

What do you get? You will see the global window object.

In a browser environment, the window object is the massive parent object that holds everything together (like your screen width, your browsing history, and built-in tools like alert()). When you use this in the open global space, JavaScript assumes you are talking about the biggest object in the room: the global window.

this Inside Objects

The most common place you will use this is inside an object's method. A method is just a function that belongs to an object.

Let's create a profile for a user:

const user = {
    name: "Suprabhat",
    age: 23,
    greet: function() {
        console.log("Hello! My name is " + this.name);
    }
};

user.greet(); // Output: Hello! My name is Suprabhat

Why did this work perfectly? Let's apply our secret rule: Who is calling the function?

Look at the line where we execute the code: user.greet(). Notice what is to the left of the dot. It is the user object. Because the user object is the one calling the greet function, JavaScript temporarily points the this pronoun directly to user. Therefore, this.name translates perfectly to user.name.

this Inside Regular Functions

Things start to get a little weird when we use this inside a normal function that is not attached to an object.

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

showThis();

If you run this code, what will be printed?

Again, ask the golden question: Who is calling the function? When you just call showThis() by itself, there is no object to the left of a dot. It is just floating out in the global space. Because of this, JavaScript defaults to the global environment. The output will once again be the global window object!

A Quick Note on Strict Mode: Because defaulting to the massive window object can cause accidental bugs, modern JavaScript introduced "strict mode" ("use strict";). If you are using strict mode, JavaScript will refuse to default to the window object. Instead, this inside a regular floating function will simply be undefined.

How Calling Context Changes this

This is the exact concept that interviewers love to test you on. You now know that this depends entirely on how a function is called. Let's see how easily we can accidentally break this by changing the caller.

Let's use our user object again:

const user = {
    name: "Suprabhat",
    age: 23,
    greet: function() {
        console.log("Hello! My name is " + this.name);
    }
};

// We assign the function to a brand new variable
const floatingGreeting = user.greet;

// Now, we call the new variable
floatingGreeting(); 

Output: "Hello! My name is undefined"

Wait, what happened? The function is the exact same code! Why did it lose the name?

Let's trace the execution:

1. We took the greet function out of the user object and stored it in a new, independent variable called floatingGreeting.

2. We executed floatingGreeting().

3. Who is calling the function? Look to the left of the parenthesis. There is no dot! There is no object!

Because floatingGreeting() was called as a regular, floating function in the global space, this stopped pointing to user and started pointing to the global window object. Since the global window does not have a property called name, this.name evaluates to undefined.

This proves our golden rule: this is not tied to where a function is written. It is entirely tied to the object calling it at the moment of execution.

Conclusion

The this keyword does not have to be intimidating. It is simply a dynamic pronoun that changes based on who is speaking.

If you ever get stuck trying to figure out what this represents in your code, don't panic. Just look for where the function is actually being executed with parentheses ().

• If there is an object to the left of the dot (e.g., myObject.myFunction()), this is that object.

• If there is no dot (e.g., myFunction()), this is the global window (or undefined in strict mode).

By shifting your focus away from where the code was written and focusing entirely on how it is called, the mystery of the this keyword completely disappears.

const user1 = {
    name: "Suprabhat",
    age: 23,
    isOnline: true
};

But what happens when your app goes viral and you suddenly have ten thousand users? Manually typing out an object for every single person is impossible. You need a factory, a reusable blueprint that can stamp out new user profiles on demand, ensuring they all have the exact same structure.

In JavaScript, we build these blueprints using Constructor Functions, and we bring them to life using the new keyword.

In this blog, we will completely demystify object creation in JavaScript. We will understand what constructor functions are, the exact step-by-step magic the new keyword performs behind the scenes, how prototypes are linked, and what it means to be an "instance."

First, let’s understand the blueprint itself: the Constructor Function.

What are Constructor Functions?

A constructor function is essentially a regular JavaScript function, but it is written with a specific purpose: to build and initialize new objects. To distinguish constructor functions from normal functions, developers follow a strict naming convention. We always capitalize the first letter of a constructor function's name.

Here is a simple example of a constructor function for our social media app:

function User(name, age) {
    this.name = name;
    this.age = age;
    this.isOnline = false;
}

Looking at this code, you might be wondering: What is this? And how does this function actually give me an object? It doesn't even have a return statement!

If you try to call this function normally by writing User("Suprabhat", 23), it will actually fail to create an object. In strict mode, it will throw an error, and in non-strict mode, it will accidentally attach the name and age variables to your global browser window.

To make this factory work, we need a special tool. We need the new keyword.

What the new Keyword Does

The new keyword is an operator in JavaScript that completely changes how a function behaves. When you place new in front of a function call, you are telling JavaScript: "Do not run this like a normal function. Run this as an object factory."

Let's use it to create our user:

const myUser = new User("Suprabhat", 23);
console.log(myUser.name); // Output: Suprabhat

By simply adding new, the function magically creates an object, assigns the properties, and returns it to us. But there is no actual "magic" in programming. The new keyword executes a very specific, hardcoded sequence of events every single time it is used.

The Object Creation Process (Step-by-Step)

When you type new User("Suprabhat", 23), JavaScript immediately pauses your code and secretly performs four crucial steps behind the scenes. Understanding these four steps is one of the most important concepts for JavaScript technical interviews.

Step 1: A brand new, empty object is created. The very first thing new does is create a blank JavaScript object out of thin air: {}.

Step 2: The this keyword is pointed to the new object. In our User function, we wrote this.name = name;. Because we used new, JavaScript takes the empty object from Step 1 and binds the this keyword to it. So, when the function says this.name = "Suprabhat", it is actually saying: "Inside this new empty object, create a property called name and set it to Suprabhat."

Step 3: The new object is linked to the constructor's prototype. This is the most powerful step. JavaScript takes the newly created object and secretly links its hidden internal [[Prototype]] property to the User.prototype object. (We will explore why this is so important in the next section).

Step 4: The new object is automatically returned. Notice how our User function did not have a return keyword? Because we used new, JavaScript automatically says: "The function is done running, I will now return the object we just built." If we were to write out what new does manually, it looks conceptually like this:

// What 'new User("Suprabhat", 23)' does behind the scenes:
function User(name, age) {
    // Step 1 & 2: Secretly creates an object and points 'this' to it
    // this = {}; 

    // Step 3: Secretly links the prototype
    // Object.setPrototypeOf(this, User.prototype);

    this.name = name;
    this.age = age;
    this.isOnline = false;

    // Step 4: Secretly returns the object
    // return this;
}

How new Links Prototypes (And Why It Matters)

Imagine you want every user in your app to have a login() function. You could write it inside the constructor like this:

function User(name, age) {
    this.name = name;
    this.age = age;
    this.login = function() {
        console.log(this.name + " has logged in.");
    };
}

This works perfectly fine, but there is a massive hidden problem: Memory Waste.

If you create 10,000 users using new User(), JavaScript will create 10,000 completely separate copies of the login function. Every single object will carry its own heavy backpack with the exact same function inside. This will severely slow down your application.

This is where Step 3 of the new keyword (linking the prototype) saves the day.

Instead of putting the function inside the constructor, we put it on the constructor's Prototype. You can think of the prototype as a shared toolshed.

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

// We put the tool in the shared toolshed
User.prototype.login = function() {
    console.log(this.name + " has logged in.");
};

const userA = new User("Suprabhat", 23);
const userB = new User("Alex", 30);

userA.login(); // Output: Suprabhat has logged in.
userB.login(); // Output: Alex has logged in.

Because the new keyword automatically links userA and userB to the User.prototype (the shared toolshed), they can both use the login function whenever they want, even though they don't directly own it! We now have 10,000 users, but only one copy of the login function in memory.

Instances Created from Constructors

Once an object is successfully created by a constructor using the new keyword, we give it a special name. We do not just call it an "object" we call it an Instance.

In our example, userA is an instance of User.

JavaScript provides a very handy built-in operator called instanceof to verify where an object came from. This is incredibly useful when you are debugging complex code and need to know which blueprint created a specific object.

console.log(userA instanceof User); // Output: true
console.log(userA instanceof Array); // Output: false

Because userA was created by new User(), and its prototype is linked to User.prototype, JavaScript confidently tells us that true, this object is indeed an instance of your User blueprint.

Conclusion

Object creation is the beating heart of JavaScript. The new keyword might look like a simple, three-letter word, but it is responsible for the heavy lifting of modern web development.

By understanding that new creates an empty object, points the this keyword, links the shared prototype toolshed, and automatically returns the finished product, you are no longer just guessing how JavaScript works. You understand the exact mechanics behind the scenes.

Constructor functions and prototypes ensure that whether your application has one user or one million, your code remains clean, efficient, and highly scalable.