Node.js Internals — An Uncle-Nephew Conversation (Hindi)🍵
DEV Community

Node.js Internals - An Uncle-Nephew Conversation (Hindi)🍵

Node.js Internals - An Uncle-Nephew Conversation (Hindi)🍵

From "why does Node.js even exist" all the way down to buffer allocation in native memory.

🪑 Saturday Afternoon

👦 Nephew: Uncle, free hai kya thoda? Saturday hai, koi plan nahi.

👨‍🦳 Uncle: Free hoon. Chai bana la, phir baith. Tu bata - kya chal raha hai aajkal?

👦 Nephew: Node.js seekh raha hoon deeply. Interviews de raha hoon, aur jab bhi "explain event loop" ya "how does Node handle 10,000 requests" jaisa sawaal aata hai, main sirf upar-upar ka jawab de pata hoon. Andar kya ho raha hai - OS level pe, libuv level pe - woh clear nahi hai. Thoda heavy lag raha hai samajhna.

👨‍🦳 Uncle: Good. Heavy lagna matlab tu sahi jagah khud rahi hai - asaan cheezein tujhe already aati hain, isiliye tujhe woh cheez heavy lag rahi hai jahan seniors bhi confuse ho jaate hain. Bol, kaunsa topic se shuru karein? Ya main crmatic taur pe shuru se shuru karoon - history se, phir architecture, phir andar ka engine?

👦 Nephew: Shuru se. Main chahta hoon ki jab interview mein poochein "why Node.js", toh main sirf "it's fast" na bolun - mujhe pura reasoning pata ho.

👨‍🦳 Uncle: Theek hai. Chai le aa. Lambi baithak hone wali hai - hum ek engineering system ki poori kahani sunenge, shuru se lekar us level tak jahan tu khud kisi junior ko sikha sake.

1. Why Node.js Was Born

👦 Nephew: Start karo - Node.js banaya kyun gaya tha?

👨‍🦳 Uncle: 2009 se pehle ka scene samajh. JavaScript sirf browser ke andar chalti thi. Uska kaam tha form validate karna, button click handle karna, thoda animation dikhana. Bas.

Browser
├── HTML
├── CSS
└── JavaScript ← sirf yahin tak, bahar nahi jaa sakti

Jab tu "Submit" dabata tha, JavaScript khud database mein data save nahi kar sakti thi. Usko kisi doosri server-side language ko call karna padta tha - PHP, Java, Python, .NET.

Browser (JS)--HTTP-->PHP / Java / Python-->Database

Ab socho tu Facebook bana raha hai. User "Like" dabata hai. Frontend JavaScript mein hai, backend Java mein hai. Iska matlab do alag teams chahiye - frontend developers aur backend developers. Alag languages, alag tooling, alag debugging, alag hiring.

Ryan Dahl naam ka engineer tha jisne yeh dekha aur simple sawaal poocha: "JavaScript already ek badhiya language hai. Yeh browser ke bahar kyun nahi chal sakti?" Usi sawaal se Node.js paida hua.

👦 Nephew: Toh Node.js ek naya language hai?

👨‍🦳 Uncle: Nahi - yeh sabse bada confusion hai jo log karte hain. Node.js ek programming language nahi hai. Yeh ek runtime environment hai. JavaScript ko browser ke bahar chalne ki jagah deta hai.

Engine: JavaScript (same engine - V8)

Environment 1: Chrome -> JS chalti hai browser ke andar
Environment 2: Node.js -> JS chalti hai machine/server ke andar

Socho JavaScript ek car ka engine hai. Sirf engine se kahin nahi ja sakte - usko ek car chahiye. Chrome ek car hai, Node.js doosri car hai. Engine same hai, gaadi alag hai.

Isiliye Node.js mein JavaScript kar sakti hai:

  • File read/write
  • Server banana
  • Database se connect hona
  • Email bhejna
  • Doosre APIs se baat karna
  • Scheduled jobs chalana

Yeh sab browser JavaScript security ki wajah se jaanbujh kar nahi kar sakti - uska hum agla topic mein dekhenge.

👦 Nephew: Toh companies ne isko adopt kyun kiya?

👨‍🦳 Uncle: Kyunki ab ek hi language - JavaScript - pura stack chala sakti thi.

React (frontend)
    |
    v
Node.js (backend)
    |
    v
MongoDB (database)

Ek language, ek hiring pipeline, shared code (jaise validation logic dono jagah reuse ho sakti hai), kam context-switching. Isi wajah se MERN stack itna popular hua.

2. The Browser Sandbox - Why Frontend Can't Touch a Database

👦 Nephew: Ek doubt tha - browser JavaScript disk se file kyun nahi padh sakti? Aur React mein toh hum already signup/signin validate karte hain, phir seedha database se connect kyun nahi kar sakte?

👨‍🦳 Uncle: Bahut acha sawaal - yeh tu ekdum backend engineer ki tarah soch raha hai.

Pehla part: socho tu ek random website kholta hai - https://kuch-bhi-site.com. Agar us site ki JavaScript ko tere poore computer ka access mil jaaye, toh woh yeh kar sakti hai:

read("C:/Users/Suraj/Documents/passwords.txt");
read("bank_details.pdf");

Yeh disaster hoga. Isiliye browser JavaScript ko ek sandbox ke andar band karke rakhta hai:

Your Computer
+--------------------------------------+
|Documents, Photos, Bank Files         |
|                                      |
| +--------------------------------+   |
| | Browser Sandbox                |   |
| | JavaScript yahin chalti hai    |   |
| | X file read nahi kar sakti     |   |
| | X DB access nahi hai           |   |
| | X server start nahi kar sakti  |   |
| +--------------------------------+   |
+--------------------------------------+

Sandbox ke andar sirf safe kaam allowed hain - DOM change karna, HTTP request bhejna, thoda localStorage use karna, ya user khud file select kare (<input type="file">) tab hi file dekhna.

👦 Nephew: Theek hai, samajh gaya. Ab doosra - React signup/signin already validate karta hai, phir bhi seedha DB connect kyun nahi?

👨‍🦳 Uncle: Socho tu React code mein likh de:

const dbPassword = "mySecretPassword";
connectToDatabase(dbPassword);

Jab React build hoti hai, uska poora JavaScript user ke browser mein bhej diya jaata hai. Matlab koi bhi DevTools khol kar tera database ka password dekh sakta hai, aur seedha:

db.users.deleteMany({});

chala sakta hai.

Isiliye database kabhi bhi browser ko directly expose nahi hoti. Uske beech mein ek backend guard khada hota hai:

React--HTTP-->Node.js (security guard)-->Database

Signup flow aisa chalta hai:

  1. React email/password collect karti hai.
  2. Node.js ko bhejti hai.
  3. Node.js validate karta hai.
  4. Password ko hash karta hai.
  5. Business rules check karta hai.
  6. DB mein save karta hai.
  7. Safe response wapas bhejta hai.

Browser ko kabhi pata nahi chalta - DB credentials, DB structure, internal logic, secret API keys - kuch bhi nahi.

Aur haan, React ki validation ("email required", "password 8 characters") sirf user experience ke liye hai - security ke liye nahi. Koi bhi banda Postman ya curl se seedha tera server hit kar sakta hai, React ko bypass karke. Isiliye backend ko har cheez dobara validate karni padti hai - kabhi bhi client se aaye data pe trust mat kar.

Golden Rule: Frontend validation = better UX. Backend validation = actual security. Kabhi mat bhoolna.

👦 Nephew: Aur ek confusion - jab main signup karta hoon, Network tab mein password plain dikhta hai. Yeh insecure nahi hai?

👨‍🦳 Uncle: Nahi, kyunki woh tera apna browser hai, tera hi data hai - sirf tu use dekh sakta hai, koi doosra nahi. Real threat tab hai jab data network pe travel karta hai - bahi HTTPS kaam aata hai:

Without HTTPS: Browser ----plain password----> Server (WiFi pe koi bhi padh sakta hai)
With HTTPS:    Browser ====encrypted data====> Server (safe)

Network tab tujhe request dikhata hai encryption se pehle, kyunki browser ko pata hai woh kya bhej raha hai. Jaise hi woh browser se nikalta hai, encrypted ho jaata hai.

3. What a "Runtime Environment" Actually Is

👦 Nephew: Uncle, "runtime environment" ka matlab exactly kya hota hai? Node.js kya deta hai jo plain JavaScript nahi deti?

👨‍🦳 Uncle: Achi cheez tu poochh raha hai - yahi cheez interview mein log gadbad karte hain.

Plain JavaScript language sirf syntax aur logic ki rules deti hai - if, for, functions, objects. Usse zyada kuch nahi. File padhna, network se baat karna - yeh language khud nahi jaanti. Yeh kaam karne ke liye usko ek "environment" chahiye jo real-world capabilities de.

JavaScript Language (ECMAScript spec)
- variables, functions, loops, objects
- NO file access, NO networking, NO timers built-in
    +
Environment (Browser YA Node.js)
- Browser deta hai: DOM, window, fetch, localStorage
- Node.js deta hai: fs, http, process, Buffer, net

Node.js ke andar teen bade parts hote hain jo milkar "runtime" banate hain:

  • V8 Engine - Google Chrome ka wahi JavaScript engine, jo JS code ko machine code mein compile karta hai.
  • libuv - ek C library jo OS ke saath baat karti hai (file system, network, timers) aur asynchronous behavior deti hai.
  • Node.js APIs (Bindings) - fs, http, crypto jaise modules jo V8 aur libuv ko JavaScript se connect karte hain.
Your JavaScript Code
        |
        v
+---------------+    +--------------+
| V8 Engine     |<-->| libuv        |
| (runs JS)     |    | (talks to OS)|
+---------------+    +--------------+
        |                  |
        v                  v
  Machine Code          OS (files, network, timers)

Isi combination ki wajah se JavaScript, jo pehle sirf browser ke andar UI manipulate karti thi, ab file system, network sockets, aur databases ke saath baat kar sakti hai.

4. Why We Need a Backend At All - Nine Real Reasons

👦 Nephew: Uncle, ek doubt - browser toh already code chala sakta hai. Toh server ki zaroorat sirf security ke liye hai ya aur bhi reasons hain?

👨‍🦳 Uncle: Security sabse bada reason hai, lekin akela reason nahi. Chal ek-ek karke dekhte hain - nau reasons hain.

  1. Security. Database passwords, API keys (OpenAI, Stripe, AWS), JWT signing secret - yeh sab kabhi browser tak nahi pahunchne chahiye.

  2. Business Logic. Socho tu Amazon bana raha hai. Koi phone khareedta hai - stock check karna, payment verify karna, coupon apply karna, tax calculate karna, inventory update karna - yeh sab business logic hai. React ko yeh decide nahi karne dena chahiye, kyunki koi bhi apne browser mein React code modify kar sakta hai.

  3. Database Access. Database trusted applications ke liye design hoti hai. Isiliye seedha Browser → Database nahi, balki Browser → Node.js → Database. Node.js decide karta hai kaunsi queries allowed hain, kaunsa row kaun access kar sakta hai.

  4. Centralized Validation. React validation sirf UX ke liye hai. Hacker Postman se seedha server hit kar sakta hai - React ko poori tarah bypass karke. Isiliye server ko sab kuch dobara validate karna padta hai.

  5. Authentication & Authorization. Token valid hai ya nahi, expire ho gaya ya nahi, yeh user admin hai ya nahi, yeh order isi user ka hai ya nahi - yeh decisions browser pe kabhi trust nahi kiye ja sakte.

  6. Communication with Other Services. OpenAI, Razorpay, Stripe, Twilio, AWS S3 - inn sab ke secret keys sirf server pe rehte hain, browser mein nahi.

  7. Heavy Computation. 2GB video upload hua - usko compress karna, alag resolutions banana, thumbnails generate karna - browser mein karna slow ya impossible hoga.

  8. Background Jobs. Welcome email bhejna, PDF generate karna, AI embeddings train karna - yeh kaam user ko wait karaye bina hone chahiye. Node.js inhe queue (jaise BullMQ) aur workers ko hand off kar deta hai.

  9. Shared Logic. Web app, Android app, iPhone app - teeno same backend call kar sakte hain. Business rules ek hi jagah rehte hain.

React (Web)
     \
Android ------> Node.js ------> Database
     /
iPhone

👦 Nephew: Toh browser ka kaam sirf...?

👨‍🦳 Uncle: UI dikhana, input lena, request bhejna, response dikhana. Bas. Yeh application ki security ya business rules enforce nahi karta.

Bahut beginners sochte hain - "frontend hi application chala raha hai." Zyada sahi tareeka sochne ka hai: Frontend ek remote control hai. Backend woh machine hai jo actual kaam karti hai.

Jab tu banking app mein "₹10,000 Transfer" dabata hai - React paisa transfer nahi karta, sirf ek request bhejta hai. Server identity verify karta hai, balance check karta hai, transaction shuru karta hai, balances update karta hai. Asli kaam server pe hota hai.

5. Blocking vs Non-Blocking - The Core Idea

👦 Nephew: Uncle, ek cheez clear karo - V8 hi JavaScript run karta hai, toh Chrome browser ko hi server ki tarah kyun nahi use kar sakte? Woh bhi toh JS run kar sakta hai.

👨‍🦳 Uncle: Bahut sharp sawaal. Yahan farak samajh - Chrome application ke roop mein OS access rakhta hai, kyunki tune usko install kiya hai, trust kiya hai. Lekin jo JavaScript kisi webpage ke andar chal rahi hai, usko woh access nahi milta - kyunki woh internet se aayi hai, usko trust nahi kiya ja sakta.

Your Computer
    |
Google Chrome ✅ OS access hai (trusted software)
    |
+---------------------------------+
| Sandbox                         |
| Webpage ki JavaScript           |
| ❌ File read nahi kar sakti     |
| ❌ Server start nahi kar sakti  |
+---------------------------------+

Node.js bilkul alag hai - woh khud ek trusted, installed software hai. Isiliye usko OS access diya jaata hai:

Your Computer
    |
Node.js
    |
JavaScript
✅ File read
✅ Server create
✅ Database access
✅ Network sockets

Same V8 engine dono jagah chalta hai - Chrome mein bhi, Node.js mein bhi. Farak environment ka hai, language ka nahi.

Ab yahan se ek key concept nikalta hai jo tera puri Node.js ki samajh badal dega: V8 kabhi disk ko directly touch nahi karta. Jab tu likhta hai fs.readFile("data.txt", callback), toh actual sequence yeh hai:

Tera code
    |
V8: "yeh JavaScript execute karo"
    |
Node.js: "yeh ek file operation hai"
    |
libuv: "OS bhai, data.txt padh de"
    |
Operating System
    |
Hard Disk / SSD
    |
File data wapas -> libuv -> Node.js -> V8 -> tera callback chalta hai

Isko restaurant se samajh:

  • 👨‍🍳 V8 = Chef - sirf JavaScript "cook" karna jaanta hai.
  • 🧑‍💼 Node.js = Manager - order leta hai, decide karta hai kya karna hai.
  • 🚚 libuv = Delivery worker - bahar jaakar OS se ingredients laata hai.
  • 🏪 Operating System = Warehouse - jahan asli resources (files, network) hain.

Chef kabhi kitchen se bahar nahi jaata. Agar ingredient chahiye, delivery worker jaata hai.

6. libuv, the Event Loop, and the Thread Pool

👦 Nephew: Toh agar fs.readFile() ko 5 second lagte hain ek badi file padhne mein, Node.js freeze kyun nahi hota?

👨‍🦳 Uncle: Isi sawaal ne Node.js ko famous banaya. Yeh dekh:

fs.readFile("bigFile.txt", (err, data) => {
    console.log("Done");
});
console.log("Hello");

Step 1 - V8 JavaScript chalana shuru karta hai, top se neeche.

Step 2 - Jab Node.js ko fs.readFile() milta hai, woh sochta hai: "Isme time lag sakta hai, main JavaScript thread ko block nahi karunga." Woh kaam libuv ko de deta hai.

Main Thread
    |
    v
libuv
    |
Worker Thread (file padhne ka kaam yahan chalta hai)

Worker thread file padhta hai, jabki main JavaScript thread aage badhta rehta hai. Isiliye console.log("Hello") turant chalta hai.

Output aata hai:

Hello
Done

Step 3 - Jab file padhna khatam hota hai, worker thread khud tera callback nahi chalata! Woh bas libuv ko bolta hai "main khatam." libuv us

Read on DEV Community ↗ ← Back to News

Comments

No comments yet. Start the discussion.