Async await created a 7-year-old bug in Node.js

🚀 Mastering res.on() Events in Node.js – The Hidden Power Behind Streams! Ever wondered how you can listen to the lifecycle of an HTTP response in Node.js? That’s where res.on() comes in — it lets you react to key response events such as when data is being sent, finished, or when something goes wrong. Let’s break it down 👇 🧠 What is res.on()? In Node.js, every HTTP response object (res) is an EventEmitter, which means we can subscribe to events like: 'data' → when data chunks are being written 'end' → when all data is sent 'error' → when something goes wrong during transmission 'close' → when the connection closes (even abruptly) This gives developers fine-grained control over network responses — a must for performance monitoring, debugging, and logging. 💡 Why Use res.on()? ✅ Monitor outgoing responses — useful for logging and analytics. ✅ Handle premature disconnects — detect if clients drop off. ✅ Improve debugging — get detailed insights into request/response flow. ✅ Enhance performance tracking — measure when responses actually complete. 🎯 Key Takeaway res.on() turns your Node.js responses into observable events — empowering you to build robust, reliable, and production-grade servers with deeper control over network behavior. #NodeJS #BackendDevelopment #WebPerformance #FullStackDevelopment #JavaScript #LearningInPublic

🚀 Just a simple custom error class in Node.js for clean error handling - The Problem Most APIs just throw Error, and then every exception looks the same in logs and responses. This makes it hard to know what really failed: Was it validation? A missing resource? Or a database timeout? - Use a custom error class I define specific error types that describe the exact problem. It helps me: ✅ return consistent API responses ✅ simplify debugging ✅ log smarter - Example with Node.js + Express (see in the image) - Why it matters ✅ Clear error hierarchy → easier to debug ✅ Consistent API responses ✅ Better observability and logs ✅ Easier unit testing - What about you? Do you use custom error classes in your Node.js projects or just throw plain errors? 👇 #Nodejs #BackendDevelopment #ErrorHandling #CleanArchitecture #SoftwareEngineering #TypeScript

🚀 Understanding Streams and Buffers in Node.js Have you ever wondered how Node.js efficiently handles large files like videos, logs, or data transfers without running out of memory? 🤔 The answer lies in Streams and Buffers — the backbone of Node.js I/O operations. A Buffer temporarily holds chunks of binary data, while a Stream processes that data piece by piece instead of loading everything at once. This approach makes Node.js incredibly efficient when dealing with big files or real-time data. Whether it’s reading a large CSV, serving a video, or handling file uploads, Streams help you process data continuously and save resources. Once you master Streams and Buffers, you can build scalable applications that handle massive data effortlessly. ⚡ 💭 Have you ever worked with file streams or HTTP streams in your Node.js projects? How was your experience? #NodeJS #JavaScript #BackendDevelopment #Streams #Buffers #Performance #WebDevelopment #Learning

When you read a file, stream a video, or send data over the network in Node.js — have you ever wondered how raw binary data gets handled so smoothly? 🧐 Let’s talk about the unsung hero behind it all — Buffer in Node.js! ⚙️ Imagine this 👇 When your computer processes files (text, images, videos), it works with 0s and 1s — pure binary. Now, JavaScript was originally built to handle text data, not raw binaries. So… how does Node.js deal with binary data? That’s where Buffer comes in — a temporary storage area for binary data. 💡 Think of it as a “holding zone” for raw bytes when Node.js talks to the file system or network. Why is Buffer so important? JavaScript strings are UTF-16 encoded — not ideal for binary data. Node.js frequently handles files, images, or network packets — all of which are binary. Buffer bridges that gap efficiently! Key Features: Fixed size (once created, size can’t change) Stores raw binary data (not UTF-8 text) Memory is allocated outside the V8 heap Global class — no need to import Super useful in: File System (fs) Networking (TCP, UDP, WebSockets) Streams (working with data chunks) Buffer vs V8 Memory 🧠 Normally, JavaScript stores data like objects and strings in V8-managed memory, which has limits (~1.4GB) and relies on garbage collection. Buffers, on the other hand, use memory directly from the OS, outside the V8 engine. This means: No garbage collection overhead Can handle larger files (3GB+) Much faster binary performance In short — Buffers = raw power for raw data. ⚡ Next time you read a file or send a network request in Node.js, remember — Buffer is silently doing the heavy lifting behind the scenes 💪 Follow me for more such content https://lnkd.in/dFzTW9wt #backend #webdevelopment #node.js #Javascript #fullstack #Mern

𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝗥𝗼𝘂𝘁𝗲𝘀 𝗶𝗻 𝗮 𝗠𝗘𝗥𝗡 𝗔𝗽𝗽 Every API request has to start somewhere — and that’s where 𝗿𝗼𝘂𝘁𝗲𝘀 come in. In 𝗘𝘅𝗽𝗿𝗲𝘀𝘀, routes define what happens when someone hits a specific endpoint. They don’t handle the logic themselves — they just decide where to send the request. When I first started, I used to dump everything inside my route files — database queries, validation, even business logic. It worked… until things got messy. Routes just 𝗱𝗶𝗿𝗲𝗰𝘁 𝘁𝗿𝗮𝗳𝗳𝗶𝗰 to the right controller. Nothing more. Once you keep routes lightweight, debugging gets easier, and your backend starts feeling structured instead of tangled. 𝗖𝗹𝗲𝗮𝗻 𝗿𝗼𝘂𝘁𝗲𝘀, 𝗰𝗹𝗲𝗮𝗿 𝗹𝗼𝗴𝗶𝗰. Now my routes look like this 👇 #MERN #Nodejs #Expressjs #BackendDevelopment #WebDevelopment #CleanCode

⚡ Codex Build Challenge | Day 10 — Connecting the Dots Between Frontend, Backend & Logic Every day feels like watching the bigger picture of development come together — today was one of those “everything clicks” days. 💡 React ⚛️ Dived deep into Redux, the core of state management in large-scale React apps: • Understood what State, Store, Actions, Reducers, and Slices are • Learned how the Redux lifecycle works — from clicking a button in UI ➡ dispatching an action ➡ updating the store ➡ re-rendering the component • Explored createSelector for optimized state reading LeetCode 💻 • Revisited LeetCode 84 (Largest Rectangle in Histogram) and Maximal Rectangle — mastering stack-based area calculation Database & SQL 💾 • Learned full CRUD — Create, Read, Update, Delete • Explored RDBMS, MySQL basics, and commands like CREATE, USE, and INSERT • Understood signed vs unsigned datatypes and differences between DDL, DML, and TCL commands OOPs in Java ☕ • Started Object-Oriented Programming — understood why we need it • Learned the four pillars of OOP and the difference between abstraction and encapsulation Each topic today felt like a building block — one connecting to another, forming the real foundation of a software engineer. 🧱 #CodexBuildChallenge #React #Redux #MySQL #OOPs #LeetCode #FullStack #DeveloperJourney #Java Tagging: Akshay Saini 🚀, Hitesh Choudhary

📸 When "Add Profile Picture" Becomes a 4-Bug Hunt Week 6: "JWT authentication complete!" ✅ Week 7: "Let's add profile picture upload!" Reality: 6 days, 21 commits, 4 debugging sessions 😅 The Challenge: ✅ Backend works (API returns 200 OK) ✅ Database saves correctly ✅ File uploads to disk ❌ Picture still won't show The Hunt: Bug #1: Path mismatch → Backend: "/uploads/profiles/user.jpg" → Frontend: "profiles/user.jpg" Bug #2: No fetch on load → Added getCurrentProfilePicture() API Bug #3: Type mismatch → profilePictureUrl vs pictureUrl Bug #4: React state not syncing → useState doesn't update with prop changes → Fixed with useEffect What Shipped: 🎯 Drag-and-drop upload 🎯 JWT-protected endpoints 🎯 Auto-delete old files 🎯 Avatar fallback (user initials) 🎯 Client + server validation The Lesson? Backend working ≠ Feature working Full-stack = debugging ALL layers 🔍 Tech: Spring Boot + React + PostgreSQL 21 commits, 1 feature, 4 bugs squashed ✅ From Hello World to real features 🚀 Repository: https://lnkd.in/gDE8vmWA #FullStackDevelopment #SpringBoot #ReactJS #Debugging #LearningInPublic

NODE JS FILE ACESS: UNDERSTANDING FOR BIGINERS AND PROS  const fs = require('fs');  This statement imports the built-in File System module  (fs) in node js. Its gives access to functions for interacting with   file System, such as; creating, reading, writing, deleting and updating   files.   fs.readFile('lorem.txt', 'utf8', (err, data) => { In the above statement the readFile() method is being called to read a file named (lorem.txt). 'utf8' tells Node.js to read the file utilizing UTF-8 encoding  that is; the file content will be retuned as a ridable text instead of raw binary data. Then argument (err) and (data) are added as a callback function that runs after the file as been read, its  captures any error that might occur ( e.g. file not found ) and also hold the actual content on the file respectively.   if (err) throw err; This line check if an error occurred during file reading, incase an error occurred  (throw err) stops the program and print error message   console.log(data) In absence of errors, this print the file content to the console Here’s how you can read files using the built-in fs module — explained line by line. Whether you’re a beginner trying to understand callbacks or a pro revising Node’s asynchronous patterns, this snippet will strengthen your grasp of Node’s core I/O system. What’s your favorite Node.js module? Let’s discuss 👇 #NodeJS #JavaScript #BackendDevelopment #WebDevelopment #CodingCommunity #LearnToCode #AsynchronousProgramming #FileSystem

I reduced my endpoint duration from 6s to 1s using this simple change. I had a REST API in my NestJS backend that was doing multiple TypeORM queries inside a transaction. Each call looked harmless. Together, they cost 5 to 6 seconds per request. Instead of adding caching or scaling the server, I combined all those separate DB calls into one well-structured SQL query. The result? 6 seconds reduced to 1 second. It’s a reminder that: - ORMs like TypeORM are great for maintainability, but they abstract away performance details. - Complex business logic often deserves raw SQL for precision and speed. - Every extra DB round-trip is a hidden tax. If you’re leading a backend or reviewing PRs, keep an eye out for: - Repeated repository calls inside loops. - Multiple queries within a single request. - Missing query profiling during code reviews. Sometimes, the fastest optimization is not a new tool or some hidden recipe, it’s writing better SQL. Curious if others still prefer ORMs for heavy logic or switch to SQL when speed matters? #NestJS #TypeORM #BackendEngineering #FullStackDevelopment #SoftwareArchitecture #DatabaseOptimization #SQLPerformance #WebPerformance #CTO #TechLeadership #SeniorDevelopers