Node.js Single-Threaded Architecture

Most of us know the Node.js Event Loop — but here’s a tricky edge case. 👀 Node.js Event Loop Priority Edge Case Outside a Promise: process.nextTick runs before queueMicrotask Inside a Promise: queueMicrotask runs before process.nextTick Do you know why? The process.nextTick queue is drained immediately after the current JavaScript execution. But inside a Promise, you're already in the microtask phase, and Node.js does not interrupt the running microtask queue. So Node.js finishes the current microtask batch first, then executes process.nextTick. Golden Rule (Node.js priority) 1. Current synchronous code 2. process.nextTick 3. Microtasks (Promise.then, queueMicrotask) 4. Timers (setTimeout) → Runs in Timers phase (inside Event loop) 5. setImmediate → Runs in Check phase (after I/O) (inside Event loop) ⚠️ Exception: When already inside a microtask, Node.js continues processing microtasks first, then runs process.nextTick. That’s the tricky part 🙂. Event loop phases (simplified) 1. timers (setTimeout) 2. pending callbacks 3. idle, prepare 4. poll (I/O happens here) 5. check (setImmediate) 6. close callbacks ⚠️Version behavior breakdown ☑️ Node.js < 11 The microtask queue was not fully standardized. ☑️ Node.js 11–14 (transition period) process.nextTick queue was always drained first, even when scheduled inside a microtask. ☑️ Node.js ≥ 15 (current behavior) Microtasks (Promise.then, queueMicrotask) are processed in FIFO order. process.nextTick still has priority at the top level, but when scheduled inside a microtask, it runs after the current microtask batch. ⚠️⚠️⚠️you may see different outputs across Node.js versions. ✅ So, while running this code, use the latest Node.js LTS version. console.log("A") //1 setTimeout(() => console.log("B"))//8 Promise.resolve().then(() => {   console.log("C") //4   setTimeout(() => console.log("C-timeout")) //11   queueMicrotask(() => console.log("C-micro")) //6   setImmediate(() => console.log("C-immediate")) //10   process.nextTick?.(() => console.log("C-nextTick"))//7 }) queueMicrotask(() => console.log("D")) //5 process.nextTick?.(() => console.log("D-nextTick"))//3 setImmediate(() => console.log("D-immediate")) //9 console.log("E") //2

𝗢𝗯𝗷𝗲𝗰𝘁𝘀 𝗶𝗻 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 You work with data in JavaScript. Objects help you organize that data. An object is a set of key-value pairs. Keys are labels. Values are the data. For example: let person = { name: "Arun", age: 22, city: "Chennai" }; Here, name, age, and city are keys. "Arun", 22, "Chennai" are values. Without objects, you would use separate variables. That gets messy. Objects keep things tidy. Objects let you: - Group related data - Model real things - Write cleaner code Why are objects essential? - They bundle data together. - They help build big applications. - They handle complex data easily. Where do you use objects? - Store user profiles - Manage products in online stores - Work with API data - Structure app information For instance, a product object: let product = { name: "Laptop", price: 50000, inStock: true }; CRUD operations are key. They stand for: - Create: Make a new object. - Read: Get data from an object. - Update: Change data in an object. - Delete: Remove data from an object. Code examples: let user = { name: "Arun" }; console.log(user.name); // Read user.name = "Maddy"; // Update user.city = "Chennai"; // Create new key delete user.branch; // Delete Objects are fundamental in JavaScript. Master them to write better code. Source: https://lnkd.in/ggRTYBce

𝑵𝒆𝒙𝒕.𝒋𝒔 𝑭𝑨𝑸 𝐐. 𝐖𝐡𝐚𝐭 𝐚𝐫𝐞 𝐭𝐡𝐞 𝐝𝐢𝐟𝐟𝐞𝐫𝐞𝐧𝐜𝐞𝐬 𝐛𝐞𝐭𝐰𝐞𝐞𝐧 𝐫𝐞𝐪𝐮𝐢𝐫𝐞() 𝐚𝐧𝐝 𝐢𝐦𝐩𝐨𝐫𝐭? Both require() and import are used to include code from other files or libraries, but they belong to different module systems. ➛ 𝒓𝒆𝒒𝒖𝒊𝒓𝒆(): Part of CommonJS, the default module system in Node.js Synchronous and works in all Node.js versions without additional configuration 𝙁𝙤𝙧 𝙚𝙭𝙖𝙢𝙥𝙡𝙚, 𝙪𝙨𝙞𝙣𝙜 𝙧𝙚𝙦𝙪𝙞𝙧𝙚(): const fs = require('fs'); ➛ 𝒊𝒎𝒑𝒐𝒓𝒕: Part of ES6 modules, offering a modern and concise syntax Asynchronous and requires enabling ES modules by adding "type": "module" to your package.json For example 𝙞𝙢𝙥𝙤𝙧𝙩 𝙛𝙨 𝙛𝙧𝙤𝙢 '𝙛𝙨'; In modern projects, import is preferred for its cleaner syntax and consistency with the broader JavaScript ecosystem, while require() remains common in older codebases. 𝐐. 𝐇𝐨𝐰 𝐝𝐨 𝐲𝐨𝐮 𝐦𝐚𝐧𝐚𝐠𝐞 𝐞𝐧𝐯𝐢𝐫𝐨𝐧𝐦𝐞𝐧𝐭 𝐯𝐚𝐫𝐢𝐚𝐛𝐥𝐞𝐬 𝐢𝐧 𝐍𝐨𝐝𝐞.𝐣𝐬? Environment variables store configuration details, such as database credentials or API keys, outside your codebase. This makes your application more secure and flexible across environments like development, testing, and production. 🔹Using dotenv (Most common method): The dotenv package is the most widely used way to manage environment variables in Node.js. 𝑯𝒆𝒓𝒆’𝒔 𝒉𝒐𝒘 𝒕𝒐 𝒖𝒔𝒆 𝒊𝒕: Install the dotenv package: npm install dotenv 𝑪𝒓𝒆𝒂𝒕𝒆 𝒂 .𝒆𝒏𝒗 𝒇𝒊𝒍𝒆: DB_HOST=localhost DB_USER=root DB_PASS=securepassword 𝑳𝒐𝒂𝒅 𝒗𝒂𝒓𝒊𝒂𝒃𝒍𝒆𝒔 𝒊𝒏 𝒚𝒐𝒖𝒓 𝒂𝒑𝒑𝒍𝒊𝒄𝒂𝒕𝒊𝒐𝒏: require('dotenv').config(); const dbHost = process.env.DB_HOST; console.log(`Connecting to database at ${dbHost}`); This approach ensures sensitive information isn’t hardcoded and makes deployment across different environments seamless. 𝐐. 𝐇𝐨𝐰 𝐝𝐨 𝐲𝐨𝐮 𝐡𝐚𝐧𝐝𝐥𝐞 𝐞𝐫𝐫𝐨𝐫𝐬 𝐢𝐧 𝐍𝐨𝐝𝐞.𝐣𝐬? Error handling is essential in Node.js, especially since many operations are asynchronous. There are several common patterns: • Using Callbacks Many asynchronous methods accept a callback with an err parameter. • Using Promises Promises handle errors with .catch(). • Using try...catch with Async/Await Async/await provides a clean way to handle errors. Each method is suited to different scenarios, but async/await is preferred in modern applications for its readability. #javascript #nodejs #backend #fullstack #development #interview #readytowork #opentowork #immediateJoiner

In a Next.js application, there are multiple ways to make API calls, depending on where and how you want to fetch data. Let’s break it down simply 👇 🔹 1. Client-side API calls (Browser) Used when data changes frequently or depends on user interaction. 👉 Using fetch JavaScript import { useEffect, useState } from "react"; export default function Users() { const [data, setData] = useState([]); useEffect(() => { fetch("https://lnkd.in/g3DWqq-p") .then(res => res.json()) .then(data => setData(data)); }, []); return ( <div> {data.map(user => <p key={user.id}>{user.name}</p>)} </div> ); } 👉 Using Axios (optional) JavaScript import axios from "axios"; useEffect(() => { axios.get("/api/users") .then(res => setData(res.data)); }, []); 🔹 2. Server-side API calls (SSR) Used when you want fresh data on every request. 👉 Using getServerSideProps JavaScript export async function getServerSideProps() { const res = await fetch("https://lnkd.in/g3DWqq-p"); const data = await res.json(); return { props: { data } }; } export default function Page({ data }) { return <div>{data.length} users</div>; } ✔ Runs on server ✔ Good for SEO + dynamic data 🔹 3. Static API calls (SSG) Used when data doesn’t change often. 👉 Using getStaticProps JavaScript export async function getStaticProps() { const res = await fetch("https://lnkd.in/g3DWqq-p"); const data = await res.json(); return { props: { data }, revalidate: 10 // ISR (re-fetch every 10 sec) }; } ✔ Pre-rendered at build time ✔ Super fast 🔹 4. API Routes (Backend inside Next.js) You can create your own API inside Next.js. 📁 pages/api/users.js JavaScript export default function handler(req, res) { res.status(200).json({ name: "Shubham" }); } Then call it: JavaScript fetch("/api/users") 🔹 5. App Router (Next.js 13+ / 14+ way) If you're using the App Router, you fetch directly in server components. JavaScript async function getData() { const res = await fetch("https://lnkd.in/g3DWqq-p"); return res.json(); } export default async function Page() { const data = await getData(); return <div>{data.length} users</div>; } ✔ Runs on server by default ✔ Cleaner and modern approach 🔹 6. Best Practices (Important for Interview) Use server-side fetching for SEO pages Use client-side for user interactions Use environment variables for API URLs Handle errors (try/catch)

🔥 Why Your Node.js API is Slow (And You Don't Know It) Most developers don't understand the Event Loop. Result: Their APIs are 10x slower than they should be. ❌ The Problem: javascript // BLOCKING - Event loop gets stuck app.get('/users', async (req, res) => { for (let i = 0; i < 1000; i++) { await db.query('SELECT * FROM users WHERE id = ?', i); } res.send(users); }); // Response time: 5 seconds 🐢 Why slow? Query 1 completes, then Query 2 starts Sequential = 1000 queries = slow death Event loop blocked waiting for each query ✅ The Fix: javascript // NON-BLOCKING - Parallel execution app.get('/users', async (req, res) => { const queries = []; for (let i = 0; i < 1000; i++) { queries.push(db.query('SELECT * FROM users WHERE id = ?', i)); } const users = await Promise.all(queries); res.send(users); }); // Response time: 500ms 🚀 What changed? All 1000 queries start immediately They run in parallel (not sequential) Promise.all() waits for all to complete 10x faster! 🔑 The Core Concept: Node.js Event Loop: Execute synchronous code Handle I/O operations (non-blocking) Return to step 1 If you force it to wait (blocking), you're wasting its superpowers. 💡 Real-World Scenarios: DATABASE QUERIES: ❌ for loop with await → sequential ✅ Promise.all() → parallel FILE OPERATIONS: ❌ fs.readFileSync() → blocks everything ✅ fs.promises.readFile() → non-blocking API CALLS: ❌ await fetch() then await fetch() → slow ✅ Promise.all([fetch(), fetch()]) → fast 🎯 Performance Gains: Scenario: Fetching 100 user records Sequential (❌): Each query: 50ms Total: 100 × 50ms = 5000ms (5 sec) Parallel (✅): All queries: 50ms Total: 50ms (database limits you) 100x faster! ⚡ Pro Tips: Use Promise.all() for independent operations Use Promise.allSettled() if some can fail Batch operations (don't query 1000 times) Connection pooling (reuse DB connections) Never use synchronous I/O (readFileSync, etc) 🔧 Quick Audit: Check your code: Any 'for' loops with 'await'? ❌ Fix it Any readFileSync()? ❌ Replace with async Any sequential API calls? ❌ Parallelize Real talk: I found 3 bottlenecks in my codebase doing this audit. Fixed them in 2 hours. API went 5x faster. What's your biggest Node.js performance issue? #NodeJS #Performance #BackendDevelopment #JavaScript #Optimization #WebDevelopment

𝐒𝐞𝐜𝐭𝐢𝐨𝐧 3: 𝐉𝐚𝐯𝐚𝐒𝐜𝐫𝐢𝐩𝐭 𝐃𝐚𝐭𝐚 𝐓𝐲𝐩𝐞𝐬 & 𝐊𝐞𝐲𝐰𝐨𝐫𝐝𝐬 🎯 𝐈𝐧𝐭𝐞𝐫𝐯𝐢𝐞𝐰 𝐐𝐮𝐞𝐬𝐭𝐢𝐨𝐧𝐬 (𝐄𝐱𝐭𝐫𝐚) 1. 𝐃𝐢𝐟𝐟𝐞𝐫𝐞𝐧𝐜𝐞 𝐛𝐞𝐭𝐰𝐞𝐞𝐧 𝐩𝐫𝐢𝐦𝐢𝐭𝐢𝐯𝐞 𝐚𝐧𝐝 𝐫𝐞𝐟𝐞𝐫𝐞𝐧𝐜𝐞 𝐭𝐲𝐩𝐞𝐬? -> Primitive: They are in the Stack memory. When you copy data from one variable to another, it creates a copy of the original data. So changing the value of one does not affect the other. Primitive → single value (number, string, boolean) -> Reference: They are in the Heap memory. When you copy, it does not copy the data but copies the address of the main data. So changing the value of one changes the other too. Reference → complex data (array, object) 2. 𝐖𝐡𝐚𝐭 𝐢𝐬 𝐭𝐲𝐩𝐞 𝐜𝐨𝐞𝐫𝐜𝐢𝐨𝐧? -> When JavaScript automatically converts one type of data to another. Example: If you write 10 + "5", JavaScript automatically converts 10 to a string and gives the result "105". This is type coercion. 3. 𝐃𝐢𝐟𝐟𝐞𝐫𝐞𝐧𝐜𝐞 𝐛𝐞𝐭𝐰𝐞𝐞𝐧 𝐧𝐮𝐥𝐥 𝐚𝐧𝐝 𝐮𝐧𝐝𝐞𝐟𝐢𝐧𝐞𝐝? -> Undefined: It means "not found" or "no value given". This is provided by JavaScript itself. -> Null: means "empty" or "nothing". This is set intentionally by the developer to indicate that there is currently nothing here. 4. 𝐖𝐡𝐚𝐭 𝐢𝐬 𝐭𝐲𝐩𝐞𝐨𝐟 𝐧𝐮𝐥𝐥 / 𝐖𝐡𝐚𝐭 𝐢𝐬 𝐭𝐡𝐞 𝐨𝐮𝐭𝐩𝐮𝐭 𝐨𝐟 𝐭𝐲𝐩𝐞𝐨𝐟 𝐧𝐮𝐥𝐥 𝐚𝐧𝐝 𝐰𝐡𝐲? (𝐈𝐦𝐩𝐨𝐫𝐭𝐚𝐧𝐭 𝐭𝐫𝐢𝐜𝐤 𝐪𝐮𝐞𝐬𝐭𝐢𝐨𝐧) -> This is an old bug in JavaScript (historical bug). When typeof null is used, the output is "object". Why? This is actually a bug in the first version of JavaScript. The developers wanted to fix it later, but by then many websites had been built based on this bug, so it was not changed. 5. 𝐖𝐡𝐚𝐭 𝐢𝐬 𝐭𝐡𝐞 𝐝𝐢𝐟𝐟𝐞𝐫𝐞𝐧𝐜𝐞 𝐢𝐧 𝐦𝐞𝐦𝐨𝐫𝐲 𝐦𝐚𝐧𝐚𝐠𝐞𝐦𝐞𝐧𝐭 𝐛𝐞𝐭𝐰𝐞𝐞𝐧 𝐩𝐫𝐢𝐦𝐢𝐭𝐢𝐯𝐞 𝐚𝐧𝐝 𝐫𝐞𝐟𝐞𝐫𝐞𝐧𝐜𝐞 𝐭𝐲𝐩𝐞 𝐝𝐚𝐭𝐚? -> Primitive: let a = 10; let b = a; b = 20; 1. Primitive data (number, string, boolean) stores direct value 2. These are in stack memory 3. When b = a is set → value is copied 4. So changing b does not change a 5. result a = 10, b = 20 -> Reference: let arr1 = [1, 2]; let arr2 = arr1; arr2[0] = 100; 1. Array/Object is stored in heap memory 2. Variable does not have actual data, but reference (address) 3. arr2 = arr1 → not copy, shares same reference 4. result arr1 = [100, 2], arr2 = [100, 2] #DotNet #AspNetCore #MVC #FullStack #SoftwareEngineering #ProgrammingTips #DeveloperLife #LearnToCode #JavaScript #JS #JavaScriptTips #JSLearning #FrontendDevelopment #WebDevelopment #CodingTips #CodeManagement #DevTools

📌Data Normalization in JavaScript. Data normalization is basically taking messy, deeply nested data and turning it into a clean, flat structure where everything is easier to access and manage. Instead of repeating the same data again and again, we can store it once and just reference it using IDs. I was working with some API data and it looked like this — users having full post objects inside them 👇 That works… but the moment data grows, updating and managing it becomes painful. So I tried normalizing it using reduce(). 💻 Code: const apiData = [ { id: 1, name: "Alpha", posts: [ { id: 11, title: "server1" }, { id: 12, title: "server2" } ], userId: 1, }, { id: 2, name: "Gama", posts: [ { id: 11, title: "server1" }, { id: 13, title: "server3" } ], userId: 2, }, { id: 3, name: "Betta", posts: [ { id: 14, title: "server4" }, { id: 12, title: "server2" } ] } ]; let result = apiData.reduce((acc, obj) => { const postIds = obj.posts.map(post => post.id); obj.posts.forEach(post => { acc.posts[post.id] = post; }); acc.person[obj.id] = { id: obj.id, name: obj.name, userId: obj.userId, posts: postIds, }; return acc; }, { person: {}, posts: {} }); console.log(result); 📦 Output: { person: { 1: { id: 1, name: "Alpha", userId: 1, posts: [11, 12] }, 2: { id: 2, name: "Gama", userId: 2, posts: [11, 13] }, 3: { id: 3, name: "Beta", userId: undefined, posts: [14, 12] } }, posts: { 11: { id: 11, title: "server1" }, 12: { id: 12, title: "server2" }, 13: { id: 13, title: "server3" }, 14: { id: 14, title: "server4" } } } #JavaScript #Frontend #Redux #WebDevelopment #Coding

🚀 **Next.js Frontend Data Fetching: Mistakes vs Best Practices (Big Scale Projects)** Frontend e data fetching properly handle na korle project ta quickly messy hoye jay 😓 Especially large-scale app e — structure na thakle maintain kora impossible. Here’s a simple breakdown from real-world experience 👇 --- ❌ **Common Mistakes (Avoid These)** • Direct component e API call kora (useEffect diye) • No caching → same request bar bar 🔁 • UI & data logic mix kora • Loading & error state ignore kora • Over-fetching unnecessary data • Duplicate API logic across components --- ✅ **Best Practices (Follow These)** 🔹 **1. Use Service Layer for Data Fetching** API call gula ekta separate layer e rakho 👇 ✔ Clean code ✔ Reusable ✔ Easy maintenance 🔹 **2. Use TanStack React Query** Async state manage korar jonno MUST use koro 👇 ✔ Smart caching ✔ Auto refetch ✔ Loading & error handling ✔ Better performance 🚀 🔹 **3. Keep Components Clean (UI Only)** Component e sudhu UI thakbe — logic na --- 🏗️ **Recommended Frontend Flow** UI Component ↓ Custom Hook (useProducts) ↓ Service Layer (API functions) ↓ Backend API --- 💡 **Why This Matters?** 👉 Without structure: Code messy, slow & hard to scale 👉 With proper flow: ✔ Clean architecture ✔ Better performance ✔ Easy to scale ✔ Developer-friendly --- ⚠️ **What NOT to Do** 🚫 Component e directly fetch koro na 🚫 Business logic + UI mix koro na 🚫 Caching ignore koro na 🚫 Same API multiple jaygay likho na --- 🔥 **Pro Tip:** “Small project e shortcut cholbe, but big project e structure is everything.” --- #NextJS #ReactJS #FrontendDevelopment #WebDevelopment #CleanCode #SoftwareArchitecture #TanStackQuery #Performance #ScalableApps

A component that owns its own data is a component you cannot reuse. This is the pattern I see repeatedly in React and Next.js codebases: a list of services, team members, or project entries hardcoded directly inside the component that renders them. It works fine until you need the same data somewhere else — then you either duplicate it or refactor under pressure. The fix is a clean separation between data and presentation. Data in the component — the problem // components/ServicesList.tsx export function ServicesList() { const services = [ { title: 'React Development', price: '€85/hr' }, { title: '.NET Backend', price: '€90/hr' }, ]; return <ul>{services.map(s => <li key={s.title}>{s.title}</li>)}</ul>; } This component cannot be tested without rendering it. The data cannot be used anywhere else without copying it. Changing a price means finding the component first. Data in lib/ — the solution // lib/services.ts export const services = [ { title: 'React Development', price: '€85/hr' }, { title: '.NET Backend', price: '€90/hr' }, ]; // components/ServicesList.tsx import { services } from '@/lib/services'; export function ServicesList() { return <ul>{services.map(s => <li key={s.title}>{s.title}</li>)}</ul>; } Now the data is importable by any component, any page, any utility function, or any test. The component is a pure rendering function. Changing the data means editing one file with no component knowledge required. This pattern scales to typed data structures, derived values, and server-side data fetching. The component stays clean. The data stays accessible. Both are independently testable and maintainable. Separation of concerns is not an architecture principle for large teams. It is a habit that pays off the first time you need the same data in two places. #react #nextjs #typescript #frontend #softwaredevelopment #webdevelopment #architecture