Code10x

Node.js ke liye ek minimal aur unopinionated web framework hai jo Node ke http module ke upar routing, middleware chain aur request/response helpers add karta hai.

Kyunki wo folder structure, database, ORM ya template engine choose karne par force nahi karta — sab decisions developer ke paas rehte hain. Isse flexibility milti hai lekin convention khud tay karni padti hai.

URL/method matching ka routing table, middleware pipeline, aur convenience helpers jaise req.params, req.query aur res.json — jo plain Node mein manually likhne padte hain.

Ek "app" jo technically ek function hai jiska signature (req, res) hai — isliye use http.createServer(app) mein directly pass kiya ja sakta hai.

Ek argument ke saath wo setting padhta hai (app.get("view engine")), do arguments ke saath wo GET route define karta hai (app.get("/users", handler)).

Server kisi port par bind nahi hoga, isliye koi request receive hi nahi hogi — process chal sakta hai lekin app "reachable" nahi hoga.

Hosting platforms apna port environment variable se assign karte hain — hardcoded port par app deploy hone ke baad start hi nahi hoga.

Request registered middleware ko order mein cross karti hai, phir matching route handler tak pahunchti hai. Har step ya to response bhejta hai (cycle khatam) ya next() karke aage pass karta hai.

Kyunki ek hi request ke liye do baar response bhejne ki koshish hui. Headers body se pehle ja chuke hote hain aur badle nahi ja sakte — aksar wajah res.json() ke aage "return" na lagana hoti hai.

HTTP method aur path ka combination jiske saath ek ya kai handler functions jude hote hain — jaise app.get("/users", handler).

Ek hi path par multiple HTTP methods chain karke likhne deta hai, jisse path repeat nahi karna padta aur CRUD routes saaf dikhte hain.

Path mein ":" se — "/users/:id" — aur handler mein req.params.id se. Values hamesha string hoti hain, number chahiye to convert karna padta hai.

req.params URL path ke dynamic segments deta hai (compulsory, route definition ka hissa), req.query "?" ke baad ke optional key-value pairs deta hai (filter/sort/pagination ke liye).

Agar uske UPAR "/users/:id" register ho gaya ho to Express pehle wahi match kar leta hai aur "me" ko id maan leta hai — specific routes hamesha dynamic routes se pehle likhne chahiye.

Ek mini-app jisme apne routes aur middleware hote hain, jise alag file mein rakhkar app.use("/prefix", router) se mount kiya ja sakta hai.

Default se child router ko parent route ke params nahi milte. mergeParams: true lagane par nested router ke andar parent ka param (jaise req.params.userId) available ho jaata hai.

Jab bhi kisi route mein wo param aata hai, uske pehle ek shared handler chalata hai — aksar id se resource load karke req par attach karne ke liye use hota hai, taaki har route mein wahi code repeat na ho.

Ek array — "?tag=a&tag=b" par req.query.tag = ["a","b"]. Agar code sirf string expect kar raha ho to crash ho sakta hai, isliye normalize karna chahiye.

Ek function jise (req, res, next) milte hain aur jo route handler se pehle chalta hai — wo request modify kar sakta hai, response bhej sakta hai, ya next() se chain aage badha sakta hai.

Request wahin atak jaati hai — na aage koi middleware chalta hai, na response jaata hai. Client timeout tak wait karta rehta hai aur koi error bhi nahi aata.

Application-level (app.use), router-level (router.use), built-in (express.json, express.static), third-party (morgan, cors, helmet), aur error-handling (chaar arguments waale).

Express unhe registration order mein chalata hai. Isliye express.json() routes se pehle hona chahiye, aur error handler aur 404 handler sabse aakhir mein — order galat hone par middleware ka koi asar hi nahi hota.

next() agli normal layer chalata hai; next(err) beech ki saari normal layers skip karke seedha error-handling middleware par pahunchta hai.

Current route ke baaki handlers skip karke agle MATCHING route par chala jaata hai — conditional routing ke liye kaam aata hai.

Mount path dekar — app.use("/admin", requireAdmin) sirf "/admin" se shuru hone waale paths par chalega. Ya middleware ko seedha route arguments mein pass karke.

Ek outer function jo options leta hai aur actual (req,res,next) middleware return karta hai — jaise requireRole("admin") ya cacheFor(300). Isse ek middleware alag settings ke saath reuse hota hai.

req object par attach karke — req.user, req.requestId, req.tenant. Aage ke middleware aur route handlers use seedha padh sakte hain.

Ya to body parser middleware mount hi nahi kiya, ya wo routes ke BAAD mount kiya, ya client ne sahi Content-Type header nahi bheja. Express default se body parse nahi karta.

express.json() "application/json" bodies parse karta hai, express.urlencoded() HTML form ka "application/x-www-form-urlencoded" data parse karta hai.

Wo qs library use karta hai jo nested objects aur arrays support karta hai (user[name]=Aarav), jabki extended: false simple querystring library use karta hai jisme sirf flat key-values aate hain.

Bina limit ke koi bhi bahut bada payload bhejkar server ki memory bhar sakta hai — ye ek denial-of-service vector hai. Default limit 100kb hai.

res.send() argument ka type dekhkar Content-Type guess karta hai (string par HTML, object par JSON), res.json() hamesha JSON serialize karke application/json bhejta hai — API ke liye res.json() clearer hai.

Sirf status code set hota hai, response jaata nahi — request hang kar jaayegi. Uske baad .json(), .send() ya .end() chahiye.

res.sendFile() file inline bhejta hai (browser use khol sakta hai), res.download() Content-Disposition: attachment set karta hai jisse browser file save karta hai.

httpOnly (JavaScript access rok, XSS se bachaav), secure (sirf HTTPS par), aur sameSite (CSRF se bachaav) — saath mein sensible maxAge.

Kyunki file uploads "multipart/form-data" mein aate hain jise express.json() parse nahi karta — multer jaisa dedicated middleware chahiye jo req.file/req.files aur req.body populate kare.

Ek folder ko publicly serve kar deta hai — "public/style.css" URL "/style.css" par mil jaati hai, har file ke liye alag route likhne ki zaroorat nahi.

Kyunki express.static() folder ke CONTENTS ko root par serve karta hai. Prefix chahiye to mount path do: app.use("/assets", express.static("public")).

express.static ke options mein maxAge (aur hashed filenames ke saath immutable) dekar — isse browser file dobara download nahi karta.

app.set("view engine", "ejs") aur app.set("views", folderPath) — engine ka npm package bhi install karna padta hai, Express khud koi engine bundle nahi karta.

<%= %> output ko HTML-escape karta hai (XSS-safe), <%- %> raw HTML daal deta hai. User input ke liye hamesha <%= %> use karna chahiye.

app.locals poore app ke liye shared variables rakhta hai (site name, version), res.locals sirf current request ke liye (logged-in user, flash message). Dono templates mein automatically available hote hain.

res.render() ka data sabse upar, phir res.locals, phir app.locals — same key hone par render ka data jeetta hai.

302 (temporary). Permanent move ke liye explicitly 301 dena padta hai, jise browser cache kar leta hai.

Browser use cache kar leta hai, isliye galti se diya gaya 301 users ke browsers mein atak jaata hai aur aasaani se undo nahi hota — pakka na ho to 302 use karo.

Uske CHAAR arguments hote hain — (err, req, res, next). Express arity dekhkar decide karta hai; teen arguments likhne par wo normal middleware ban jaata hai aur errors nahi pakadta.

Sabse aakhir mein — saare routes aur 404 handler ke baad. Routes se pehle lagane par wo kabhi errors receive hi nahi karega.

Express handler ko synchronously call karta hai aur sirf sync throws pakadta hai. Async function turant promise return karta hai, rejection baad mein aata hai jab Express ka try/catch khatam ho chuka hota hai — request hang ho jaati hai.

Ek wrapper jo handler ke promise par .catch(next) laga de — asyncH(fn). Express 5 mein ye built-in ho gaya hai, wrapper ki zaroorat nahi rehti.

Status code aur message error object mein hi aa jaate hain, jisse error handler ko ek hi shape samajhni padti hai, aur operational (4xx) vs programmer (5xx) errors alag treat kiye ja sakte hain.

Saare routes ke BAAD aur error handler se PEHLE. Pehle laga diya to har request wahin ruk jaayegi aur asli routes kabhi nahi chalenge.

app.use() har HTTP method (GET, POST, PUT, DELETE) par chalta hai, jabki app.get("*") sirf GET requests pakadta hai.

Stack trace aur internal details — usme file paths aur code structure hota hai jo attacker ke liye reconnaissance ban jaata hai. Stack server par log karo, client ko generic message do.

morgan har HTTP request ko log karta hai (dev/combined formats), aur DEBUG=express:* Express ke internal routing aur middleware matching ka trace dikhata hai — "route match KYU nahi hua" debug karne ke liye.

URL mein resource (noun) hona chahiye aur action HTTP method se aana chahiye — "GET /users" sahi hai, "/getUsers" nahi. Collections plural rakhte hain.

PUT poora resource replace karta hai — jo fields nahi bheje wo hat jaate hain. PATCH sirf bheje gaye fields update karta hai.

201 Created, aur best practice hai naye resource ka URL Location header mein bhejna.

Jab operation safal ho lekin bhejne ke liye koi body na ho — jaise successful DELETE. 204 ke saath body bhejna spec ke against hai.

401 Unauthorized ka matlab hai "tum kaun ho pata nahi, authenticate karo"; 403 Forbidden ka matlab hai "pata hai tum kaun ho, lekin ye karne ki permission nahi".

400 Bad Request malformed request ke liye (jaise invalid JSON), 422 Unprocessable Entity tab jab syntax sahi ho lekin values business rules fail karein (jaise age = -5).

Client ka error handling, monitoring alerts, retry logic aur caching sab status code par depend karte hain — sab par 200 bhejne se wo sab bekaar ho jaate hain.

Bina limit ke ek query poora table return kar sakti hai, jo memory, network aur database — teenon ko gira sakti hai. Limit par hard cap bhi lagana chahiye.

Joi, Zod ya express-validator — validation middleware ke roop mein route se pehle, taaki galat data DB tak pahunche hi na. Body ke saath params aur query bhi validate karne chahiye.

Ek saath kai security-related HTTP headers set karta hai — CSP, HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy — aur X-Powered-By hata deta hai.

Wo attacker ko bata deta hai ki app Express par chal raha hai, jisse framework-specific vulnerabilities target karna aasaan ho jaata hai. app.disable("x-powered-by") ya helmet se hat jaata hai.

Strict policy inline scripts aur external CDNs block kar deti hai, jisse existing pages tut sakte hain. Isliye pehle report-only mode mein violations dekhni chahiye, phir enforce karna chahiye.

Kyunki CORS restriction BROWSER lagata hai, server nahi. Postman jaise tools same-origin policy enforce nahi karte, isliye wahan request normally chalti hai.

Non-simple requests (PUT/DELETE, custom headers, JSON content-type) se pehle browser ek OPTIONS request bhejta hai ye poochhne ke liye ki asli request allowed hai ya nahi.

Browser cookies ke saath wildcard origin ko explicitly reject karta hai — credentials bhejne ke liye exact origin dena zaroori hai.

API abuse aur brute-force attacks rokne ke liye — poore API par ek general limit, aur login/OTP/password-reset jaise sensitive endpoints par bahut tight limit.

Sab requests proxy ki ek hi IP se lagti hain, isliye limit sabko ek saath block kar deti hai. app.set("trust proxy", 1) lagane par Express X-Forwarded-For se real client IP leta hai.

Har instance apna alag counter rakhta hai, isliye 4 instances par effective limit 4 guna ho jaati hai — Redis jaisa shared store chahiye.

Header (algorithm), payload (claims jaise sub, role, exp), aur signature — dot se separated, teenon base64url encoded.

Payload sirf ENCODED hai, ENCRYPTED nahi — koi bhi use base64-decode karke padh sakta hai. Signature sirf tampering rokta hai, chhupaata kuch nahi.

Kyunki issued JWT ko revoke karna mushkil hai — server ke paas uska record nahi hota. Short expiry (15-30 min) + refresh token chori hue token ka window chhota kar deta hai.

Session stateful hai — revoke karna aasaan, lekin shared store chahiye. JWT stateless hai — scale karna aasaan, lekin revoke karna mushkil aur token bada hota hai.

Server restart par saare sessions ud jaate hain, memory leak karta hai, aur multiple instances ke beech share nahi hota — production mein Redis ya DB store chahiye.

Taaki test mein app import karke bina port bind kiye HTTP requests simulate ki ja sakein — warna har test file listen karne ki koshish karegi aur port conflict hoga.

Express view template caching on kar deta hai aur error responses se stack traces hata deta hai, aur kai libraries apne dev-only checks band kar deti hain — performance aur security dono improve hote hain.

Multiple worker processes chalata hai jo ek hi port share karte hain, jisse saare CPU cores use hote hain. Saath mein crash par auto-restart aur zero-downtime reload bhi milta hai.

SIGTERM par server.close() se naye connections lena band karo, chal rahi requests poori hone do, DB connections band karo, phir exit — saath mein ek timeout rakho taaki hang hone par process force exit ho jaaye.