DEV Community: Rohit Giri

Nodejs : from Hate to love

Rohit Giri — Sun, 07 Jun 2026 04:35:23 +0000

"simplicity is the ultimate sophistication" by "leonardo da vinci".To understand it I spend a lot of my precious time. I was the guy who was curious about the technology when nobody around me cares about it. When i started to learn web i found that there is the one ultimate language that is essential to learn is javascript initially it was suck. Every one who used javascript knows about it. for those who dont know let me give you examples.

[] + []
// ""

Both arrays become empty strings during type coercion.

[] + {}
// "[object Object]"

but

{} + []
// 0

Because the first {} can be interpreted as an empty block, not an object.

NaN === NaN
// false

Because NaN is defined as “not equal to anything, including itself.”

for a learner it was very difficult to understand all these things because at first they do not make any sense.
By the time the frustration suddenly start making sense and the hate for javascript became love.

From Frustration to Love: The Node.js Features That Changed Everything

There's a specific moment every developer knows — the one where JavaScript stops being the enemy and starts making sense. Where the chaos of callbacks and the weirdness of this suddenly clicks, and you realize the language wasn't broken. You just hadn't seen it from the right angle yet.

For me, that angle was the backend. Specifically, Node.js.

I chose Node.js as my go-to when I started learning backend development, and it wasn't a random pick. The more I worked with it, the more I found myself genuinely excited about how it operates under the hood. So let me walk you through the three features that made me fall in love with it — not as bullet points in a docs page, but as real ideas worth understanding.

1. The Event Loop — Node's Beating Heart

If you've ever been told "JavaScript is single-threaded," you probably followed that up with a confused — "then how does it handle thousands of requests?"

That's the Event Loop doing its job.

Node.js is built on a reactor pattern. At its core, there's a single-threaded event loop backed by a non-blocking I/O model, powered by libuv under the hood. Instead of spinning up a new thread for every incoming request (the way traditional servers like Apache do), Node registers an event handler and moves on. When the I/O operation completes — a database query, a file read, a network call — the result is pushed into the event queue. The event loop picks it up and runs your callback.

Here's what that looks like in practice:

const fs = require('fs');

console.log('Start');

fs.readFile('data.txt', 'utf8', (err, data) => {
  if (err) throw err;
  console.log('File contents:', data);
});

console.log('End');

Output:

Start
End
File contents: ...

Notice that End prints before the file is read. Node didn't sit around waiting. It registered the callback, kept moving, and came back when the file was ready. This is non-blocking I/O in its simplest form.

The event loop itself cycles through multiple phases — timers, pending callbacks, idle, poll, check, and close callbacks — in a precise order. The poll phase is where the loop waits for new I/O events. The check phase is where setImmediate() callbacks run. Understanding this order is what separates developers who use Node from those who truly understand it.

This architecture is why Node.js can handle tens of thousands of concurrent connections with a fraction of the memory a thread-per-request model would need. It's not magic — it's a very deliberate design choice, and it's one of the most elegant ideas in modern server-side development.

2. The Module System — Building Blocks, Your Way

Every serious application is just well-organized modules talking to each other. Node.js understood this early, and the module system it offers gives you both structure and flexibility.

Node originally used CommonJS (require / module.exports), and it still works beautifully. The modern ecosystem has also embraced ES Modules (import / export). But beyond the syntax, what's interesting is how you design your modules — and the patterns you can apply.

The Basic CommonJS Module

// greet.js
function greet(name) {
  return `Hello, ${name}! Welcome to Node.js.`;
}

module.exports = { greet };

// app.js
const { greet } = require('./greet');
console.log(greet('Arjun'));

Clean, simple, predictable. But now let's go deeper.

Pattern 1 — The Singleton Module

In Node.js, modules are cached after the first require(). This means that every time you import the same module, you get the same instance. This is the singleton pattern, built right into the runtime — for free.

// config.js
const config = {
  db: 'mongodb://localhost:27017/myapp',
  port: 3000,
};

module.exports = config;

No matter how many files require('./config'), they all share the same object. Change a property in one place, and it reflects everywhere. This is incredibly useful for shared state like database connections or application configuration.

Pattern 2 — The Factory Module

Sometimes you don't want a singleton. You want the module to create something fresh each time it's called. That's the factory pattern.

// logger.js
function createLogger(prefix) {
  return {
    log: (msg) => console.log(`[${prefix}] ${msg}`),
    error: (msg) => console.error(`[${prefix}] ERROR: ${msg}`),
  };
}

module.exports = createLogger;

// app.js
const createLogger = require('./logger');

const authLogger = createLogger('Auth');
const dbLogger = createLogger('Database');

authLogger.log('User logged in');
dbLogger.error('Connection failed');

Now you have independent loggers, each with their own context — all from the same module file.

Pattern 3 — The Revealing Module Pattern

This pattern lets you control exactly what's public and what stays private, mimicking class-level encapsulation without needing a class at all.

// counter.js
let count = 0;

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

module.exports = { increment, decrement, getCount };

The variable count is private — nobody outside this module can directly mutate it. They can only interact through the exposed API. This is clean, safe, and exactly how well-designed libraries work.

The module system isn't just a convenience — it's an architectural tool. Learning to design modules intentionally is what takes a Node project from a pile of files to something maintainable and scalable.

3. Full-Stack JavaScript — The Unfair Advantage

This one doesn't get talked about enough.

When you write a Python or Ruby backend, you're working in one language on the server and JavaScript on the client. That means two mental models, two sets of tooling, two type systems (or lack thereof), and inevitable translation overhead when data moves between them.

Node.js removes that boundary entirely.

Shared Code Between Frontend and Backend

Here's a real example. Say you have form validation logic:

// shared/validators.js
function isValidEmail(email) {
  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
}

function isStrongPassword(password) {
  return password.length >= 8 && /[A-Z]/.test(password) && /[0-9]/.test(password);
}

module.exports = { isValidEmail, isStrongPassword };

This exact file can be imported in your Express API to validate request bodies and bundled into your React or Vue frontend to validate forms before submission. One source of truth. Zero duplication.

In Python, you'd write this logic twice — once in Python for the server, once in JavaScript for the browser. Every time the rules change, you update two places and hope they stay in sync.

JSON is Native

JavaScript and JSON share the same DNA — JSON literally stands for JavaScript Object Notation. When your Node.js backend fetches data from a database and sends it to a React frontend, there's no serialization friction. Objects flow naturally.

// Express API
app.get('/user/:id', async (req, res) => {
  const user = await db.findUser(req.params.id);
  res.json(user); // Plain JS object → JSON response, zero effort
});

// React Frontend
const response = await fetch('/user/42');
const user = await response.json(); // Back to a plain JS object
console.log(user.name);

Compare this to Python's Flask or Django, where you often need to define serializers, handle type conversions, and map between Python data structures and JSON representations. It's doable, but it adds layers. With Node.js, there are no layers.

One Language, One Team

For startups and small teams especially, this is transformative. A frontend developer can contribute to the backend without switching languages. A backend developer can fix a UI bug without re-learning syntax. Code reviews become easier because everyone can read everything.

This is an advantage that no other backend language can honestly claim — because no other language is the browser's language.

The Bigger Picture

Node.js won me over not because it's the easiest tool or the most feature-rich. It won me over because it's coherent. The event loop is a logical response to I/O-bound workloads. The module system gives you just enough structure without imposing a rigid framework. And full-stack JavaScript isn't just a convenience — it's a genuine competitive advantage.

The hate for JavaScript makes sense in hindsight. We encounter it first in the browser, in its messiest, most inconsistent form — DOM manipulation, browser quirks, the infamous this. But Node.js gave JavaScript a second context, a cleaner one, with real tooling and a clear purpose.

And that's when the frustration started making sense.

for those who says nodejs has lot of issues like we say in hindi "दाग तो चाँद में भी होते हैं।" Even the moon has scars. That never stopped anyone from looking up.

If you're a backend developer, understanding HTTP deeply will make debugging 10x easier.

Rohit Giri — Sun, 01 Feb 2026 07:31:39 +0000

Backend Without HTTP: How Would the Web Work?

Rohit Giri ・ Feb 1

#backend #beginners #networking #webdev

Backend Without HTTP: How Would the Web Work?

Rohit Giri — Sun, 01 Feb 2026 07:28:46 +0000

Ever wondered what life without HTTP (HyperText Transfer Protocol) would look like?
It would feel like trying to send a letter without a postman — you have a message, but no reliable way to deliver it to the right place.

To truly understand that, we first need to answer a simple question:

What is HTTP?

And no — not the boring “it stands for HyperText Transfer Protocol” answer

In this article, we’ll explore HTTP from a low-level perspective: how it actually works behind the scenes, how requests and responses travel, and what really happens when you type a URL and hit Enter.

How Do Computers Communicate?

Before we understand HTTP (a protocol used to send data on the web), we first need to understand how computers actually communicate.

Imagine you want to send a message from Person A to Person B. There can be two situations:

Both live in the same house
→ Communication is easy and direct.

They live in different houses
→ You need a proper addressing system so the message reaches the correct destination.

Computers work in a very similar way.

In networking, communication also happens in two common scenarios:

1) Devices are in the same network (same local area network / same router)

2) Devices are in different networks (across cities or countries)

To make sure the message reaches the correct device, every device needs an address.

That address is called an IP Address.

👉 Think of an IP address like your house address — it tells the network where exactly to deliver the data.

what makes HTTP unique

there are a lot of things that are great but one thing that i like the most it is stateless. Stateless means that it has no memory of past interactions every request is treated as a new request. It simplify the server architecture by not storing session information. Now you will say how the hell developer handle the state management. I said state will not be managed by the server that does not mean it will not be managed by client also, developer can manage the state by storing all necessary information in cookies, session and tokens.

Client Server model

Http works on client server model, Where client send Http request and server respond with Http response.

Evolution of HTTP

HTTP 1.0: Opened a new connection for each request, leading to inefficiencies.

HTTP 1.1: Introduced persistent connections, allowing multiple requests and responses over a single TCP connection, significantly improving performance. It also added chunk transfer encoding and better caching mechanisms.

HTTP 2.0: Introduced multiplexing, allowing multiple requests/responses over a single connection using binary framing instead of text. It supports header compression and server push.

HTTP 3.0: Built on the QUIC protocol (over UDP) for faster connection establishment, reduced latency, and better packet loss handling. It continues to support multiplexing without head-of-line blocking.

HTTP Request Send By Client

<method> <request-target> <protocol>
<request-headers>
<representational-headers>
<request-body>

Method
it can be GET, POST, PUT etc.

request-target
it can be absolute or relative URL.

protocol
The HTTP version it can be any that we have discussed above like HTTP 1.0,HTTP 2.0 etc.

request-headers
Headers are metadata sent with a request after the start line and before the body. refer the below example.

Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 49

representational-headers

Representation headers are sent in a request if the message has a body, and they describe the original form of the message data and any encoding applied. this is very important for the recipient to understand how to handle the body part of the request properly.

Content-Type: application/json

Request-Body
Typically Only PATCH, POST, and PUT requests have a body.

{
  "firstName": "Rohit",
  "lastName": "Giri",
  "email": "rg123@ai.com",
}

Request body can contain additional information required by the server to process any request.

HTTP Response Send By Server

A wise man said that if you understand the response send by the server you can debug any Http request and response. By the way i said this 😅.

below is the Wireframe of Http response.

<protocol> <status-code> <reason-phrase>
<Response-Header>
<Representational-Header>
<Request-Body>

below is the real example of response Send by Server

HTTP/1.1 201 Created
Content-Type: application/json
Location: http://Arkaai.dev/users/123

{
  "message": "New user created",
  "user": {
    "id": 123,
    "firstName": "Rohit",
    "lastName": "Giri",
    "email": "rg123@ai.com"
  }
}

Status-Code
It is very important to understand the Status-Code. Http has 5 types of Status code. These codes tell us the result of the request made by the client (browser/app) to the server.

1. 1xx → Informational

Meaning: Request received, processing continues

Used rarely in real websites.

Examples:

100 Continue → Server says “ok, send the body”
101 Switching Protocols → Upgrading protocol (like HTTP → WebSocket)

2. 2xx → Success

Meaning: Request successfully completed

Examples:

200 OK → Request success
201 Created → New resource created (mostly in POST)
204 No Content → Success but no response body

3. 3xx → Redirection

Meaning: Client needs to take another action / moved

Examples:

301 Moved Permanently → URL changed permanently
302 Found / Temporary Redirect → temporarily moved
304 Not Modified → use cache, no need to download again

4. 4xx → Client Error

Meaning: Problem from client side (wrong request, invalid URL, etc.)

Examples:

400 Bad Request → wrong format / invalid data
401 Unauthorized → login required
403 Forbidden → not allowed even after login
404 Not Found → page/resource not found
429 Too Many Requests → rate limit exceeded

5. 5xx → Server Error

Meaning: Server failed to process correct request

Examples:

500 Internal Server Error → server crashed or bug
502 Bad Gateway → server got invalid response from another server
503 Service Unavailable → server down / overload
504 Gateway Timeout → server didn’t respond in time

Idempotent VS Non-Idempotent

Idempotent methods can be called multiple times with the same result.
Examples (Idempotent methods):

GET → only fetch data
PUT → update/replace resource (same data again = same final state)
DELETE → delete resource (deleting again won’t change more)
HEAD / OPTIONS → metadata only

Non-idempotent methods that can produce different result on every call.
Examples (Non-idempotent methods):

POST → creates new resource every time

Options method and CORS workflow

OPTIONS Method: Used to fetch the capabilities of a server for a cross-origin request. Not directly used by developers but seen in browser network tabs as "pre-flight requests".
Same-Origin Policy (SOP): Browsers restrict web pages from making requests to a domain different from their own.
Cross-Origin Resource Sharing(CORS): A security mechanism enforced by browsers to control how web applications interact with resources on different domains.

basically there are two types of request Simple Request and Pre-flighted Request

Simple Request Flow:
Used for methods like GET, POST, or HEAD.
The client sends a request with an Origin header.
The server checks the Origin header against its CORS policy and, if allowed, includes Access-Control-Allow-Origin in the response.
If the header is absent or doesn't match, the browser blocks the response.

Pre-flight Request Flow:
Triggered when conditions like non-simple HTTP methods (e.g., PUT, DELETE), custom headers, or specific Content-Type values are used.
The browser sends an OPTIONS request before the actual request. This inquiry asks the server if the intended method, headers, and origin are allowed.
The server responds with Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, and Access-Control-Max-Age (to cache pre-flight results).
If the pre-flight request is successful (status 204 No Content), the browser sends the original request.

OPTIONS /resource/foo
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: x-requested-with
Origin: https://arkaai.dev

Example Response of pre-flighted request

HTTP/1.1 204 No Content
Connection: keep-alive
Access-Control-Allow-Origin: https://arkaai.dev
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE
Access-Control-Allow-Headers: X-Requested-With
Access-Control-Max-Age: 86400

HTTP Caching

Purpose: Stores copies of frequently accessed resources to reduce server load and improve performance.

Mechanism: When a client requests a resource, the cache determines if it has a fresh copy. If so, it serves the cached version. If not, it fetches from the server.

Cache Headers

Cache-Control: Primary header for controlling caching behavior (e.g., no-store, no-cache, max-age, public, private).
Expires: Provides an absolute expiration date/time.
ETag: Unique identifier for a resource's content. Used for conditional requests.
Last-Modified: Timestamp of when the resource was last modified.
Conditional Requests: Clients send headers like If-None-Match (with ETag) or If-Modified-Since (with Last-Modified). If the resource hasn't changed, the server responds with 304 Not Modified, telling the client to use its cached version.

Persistent Connections and Keep-Alive

Persistent Connections (HTTP 1.1+): Keep the TCP connection open after a request/response, allowing multiple requests to be sent over the same connection. This avoids the overhead of establishing a new connection for each request.
Connection: keep-alive Header: Instructs the server to keep the connection open.

HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Thu, 11 jan 2026 15:23:13 GMT
Keep-Alive: timeout=5, max=200
Last-Modified: Mon, 10 jan 2026 04:32:39 GMT
Server: Apache

(body)

Conclusion

HTTP is not just “a protocol that transfers hypertext” — it’s the core communication language of the web. Every time we open a website, log in, stream content, or call an API, HTTP quietly manages the conversation between the client and the server.

In this article, we didn’t look at HTTP as a textbook definition — we broke it down from the ground up: how computers communicate using IP addresses, how the client-server model works, how HTTP requests and responses are structured, and why status codes are essential for debugging.

We also explored how HTTP evolved from HTTP/1.0 to HTTP/3, and why features like persistent connections, multiplexing, QUIC, and caching matter for performance. Concepts like idempotency help us design safer APIs, and workflows like CORS + preflight requests explain why browsers behave differently than tools like Postman.

Once you understand HTTP deeply, you don’t just use the internet — you understand what’s happening behind it.

And that’s what turns a normal developer into someone who can build, debug, and scale real-world applications confidently. 🚀🔥