Manish Kumar’s Post

🧵 AbortController in Node.js — An Underrated Tool We Rarely Use Most Node.js applications keep processing a request even after the client disconnects. That means: • DB queries keep running • API calls continue • CPU & memory are wasted Node.js already gives us a clean solution — AbortController — but many of us don’t use it enough. 🔧 What AbortController Actually Does It allows you to pass a cancellation signal from the client layer down to lower layers — database calls, fetch requests, background operations. When the client cancels the request: ➡️ the signal propagates ➡️ ongoing work can stop gracefully ➡️ resources are freed early 🧠 Why This Matters • Better performance under load • Reduced unnecessary work • Cleaner request lifecycle handling • More resilient APIs ⚙️ Where It Fits Well • External API calls • Long-running computations • File uploads / streaming • Search, analytics, or aggregation APIs 🧩 Mental Model Think of AbortController as a “stop signal” flowing through your application stack — from the client, through the API, into every async operation that supports cancellation. 👉 We often talk about scaling systems, but request cancellation is part of good system design too. Worth revisiting this in your Node.js services. #NodeJS #BackendEngineering #SystemDesign #JavaScript #WebPerformance

🚀 How Node.js Handles Real Production Load In real-world systems, scalability isn’t about frameworks — it’s about how data and traffic are handled. 🔹 Buffers handle raw binary data (files, images, videos) efficiently. 🔹 Streams process large data chunk by chunk, avoiding memory overload. 🔹 Backpressure automatically slows producers when consumers are slow, keeping servers stable. 🔹 Clusters fork multiple worker processes to utilize all CPU cores and handle high traffic. Together, these are what make Node.js production-ready, not just fast on paper. 💡 Scalability in Node.js is engineered — not accidental. #NodeJS #BackendDevelopment #Scalability #SystemDesign #JavaScript

Node.js (18+) is quietly replacing many utility packages we used to install by default. I’ve stopped reaching for npm install as my first instinct. A lot of things we used to rely on small dependencies for now exist natively: • Load environment variables -> node --env-file • Test runner -> node:test • File watching -> node --watch • HTTP requests -> global fetch This doesn’t mean external libraries are obsolete, they still offer richer ecosystems. But for many internal tools, scripts, and smaller services, native Node features are now enough. Fewer dependencies means: • Smaller attack surface • Faster installs • Simpler CI/CD • Less maintenance overhead Sometimes the cleanest architecture decision isn’t adding a better library, it’s not adding one at all. #NodeJS #JavaScript #BackendDevelopment #SoftwareEngineering #CleanCode

🚀 Handling Heavy Computation in Node.js Node.js (and Express) runs JavaScript on a single-threaded event loop. While async I/O is non-blocking, CPU-intensive tasks are not. ⚠️ What happens if one API performs heavy calculations? • The event loop gets blocked • Other user requests wait or time out • Overall application performance degrades Approaches to solve this 1️⃣ Cluster Mode Run multiple Node.js processes to utilize all CPU cores. Helps distribute traffic, but a heavy request can still block one worker. 2️⃣ Worker Threads Offload CPU-heavy logic to worker threads. Keeps the main thread responsive and enables true parallel computation. 3️⃣ Background Job Queues (Best Practice) Move long-running tasks to background workers using tools like BullMQ + Redis. APIs remain fast, scalable, and resilient. 4️⃣ Horizontal Scaling Scale instances behind a load balancer—but remember, scaling alone doesn’t fix blocking logic. 💡 Key takeaway: Use Node.js for fast I/O, and never let CPU-heavy work block your event loop. Offload, parallelize, or background it. #NodeJS #ExpressJS #BackendEngineering #Scalability

🚀 Identifying and Resolving Memory Leaks in Node.js Applications Memory leaks in a Node.js application can silently degrade performance, increase response time, and eventually crash your server. As backend developers, it’s crucial to proactively monitor memory usage and identify abnormal growth patterns. The attached document will help you to understand the below points: 🔍 How to detect memory leaks using heap snapshots and profiling tools 🧠 Common causes like unremoved event listeners, global variables, closures, and unbounded caches 🛠️ Using tools like Chrome DevTools, Node.js heapdump, and monitoring with PM2 ✅ Practical strategies to fix and prevent leaks in production Understanding memory behavior isn’t just about fixing bugs — it’s about building scalable and reliable backend systems. #NodeJS #BackendDevelopment #JavaScript #MemoryLeak #PerformanceOptimization #FullStackDeveloper #SystemDesign #Debugging #SoftwareEngineering #DevTips

Today I published my first open-source npm package: payload-sanitizer 🎉 I realized I was doing the same payload-cleaning logic again and again in almost every project (forms, filters, query params). So I decided to package it properly and contribute something small but useful for other developers. payload-sanitizer is a tiny zero-dependency utility for JS/TS (frontend + backend) that cleans payloads before you send them to an API or build DB queries: 1. removes undefined, null, empty/whitespace strings, and optional "-" 2. trims strings 3. deep cleans objects + arrays 4. can drop empty objects/arrays 5. supports path-based rules (keepPaths / dropPaths) Works great as an Express middleware pattern Why not just Zod? Zod is amazing for validation + schema parsing. This library is different: it’s for sanitizing/normalizing payloads (schema-less) before validation or querying. They work great together: sanitize → validate. npm: https://lnkd.in/djvi5CiD GitHub: https://lnkd.in/d9Nvgd-6 Docs: https://lnkd.in/d7SUuZja If you find edge cases or want to contribute, PRs/issues are welcome 🙌 #opensource #typescript #javascript #npm #nodejs #react #express

libuv Thread Pool — the hidden workers behind Node.js Node.js is single-threaded… but not everything runs on the event loop. One of the most misunderstood parts of Node.js is the libuv thread pool. When we say Node.js is non-blocking, what we really mean is this: blocking work is quietly offloaded somewhere else. That “somewhere else” is the libuv thread pool. What actually runs in the thread pool File system operations DNS lookups Compression and crypto Some native addons These tasks don’t block the event loop directly. They are executed by background worker threads managed by libuv. Why this matters in real applications The thread pool has a default size of 4 threads. If all of them are busy, new tasks wait in a queue. This is why: – Heavy file uploads can slow down unrelated requests – CPU-heavy crypto can impact API latency – “Async” code can still cause performance issues Nothing is blocked… but everything is waiting. A common production mistake Assuming async APIs mean unlimited parallelism. They don’t. If you overload the thread pool, your app stays alive but becomes slow and unpredictable. How experienced teams handle this Avoid CPU-heavy work on API servers Use streams instead of buffering large files Tune UV_THREADPOOL_SIZE only when you understand the trade-offs Offload heavy processing to workers or separate services The key takeaway Node.js performance issues are rarely about JavaScript. They’re usually about understanding what runs on the event loop and what doesn’t. Once you understand the libuv thread pool, many “mysterious” Node.js bottlenecks suddenly make sense. #NodeJS #BackendEngineering #SystemDesign #JavaScript #WebPerformance #NodeInternals #SoftwareArchitecture #FullStackDevelopment

𝗧𝗶𝗽𝘀 𝗳𝗼𝗿 𝗕𝗲𝘁𝘁𝗲𝗿 𝗡𝗼𝗱𝗲.𝗷𝘀 𝗖𝗼𝗱𝗲 You want to write good Node.js code. Here are some tips to help you: - Use async/await to avoid callback hell - Handle errors to prevent crashes - Do not hardcode configuration values - Organize your code into logical modules - Log events to debug and monitor your application - Validate user input to prevent security issues - Use connection pooling for database queries - Implement rate limiting to prevent abuse - Use caching to reduce response time These tips will help you write better Node.js code. Start with one or two tips and build from there. Some next steps: - Set up a CI/CD pipeline - Write unit and integration tests - Monitor your application with tools like Prometheus and Grafana - Consider using TypeScript Good code is about maintainability, scalability, and performance. Follow these tips to become a better Node.js developer. Source: https://lnkd.in/gNEFFuex

Why My Node.js Server Never Handles Media in QuickScreen. When building QuickScreen, one decision shaped the entire system: the backend never touches screen data. This wasn’t a WebRTC requirement — it was an architectural choice. Here’s what this decision unlocked: • Scalability If media passed through Node.js, every new user would multiply server bandwidth and CPU usage. By keeping media peer-to-peer, the server only handles lightweight signaling messages. • Latency Removing the server from the media path eliminates an entire network hop. This directly improves screen-sharing responsiveness. • Cost & simplicity No media processing means: - No transcoding - No media pipelines - No bandwidth-heavy infrastructure • Reliability When direct P2P fails, TURN servers relay traffic without turning the app server into a bottleneck. • Privacy by design Screen content flows browser-to-browser, encrypted with SRTP. The backend cannot access user screens at any point. The real lesson • Node.js coordinates connections. • WebRTC transports media. Understanding what not to put on your server is just as important as knowing what to build. Tech: React, Node.js, Express, Socket.IO, WebRTC Live demo and GitHub are in comments. #WebRTC #NodeJS #SystemDesign #FullStackDeveloper #MERN #JavaScript #RealTimeApps

Node.js streams leak memory. Silent crashes follow. A user pauses a large upload. Your server keeps the connection open, buffering data forever. One slow client can crash your entire process. I got tired of writing manual timeouts and memory checks for every file handler. So I built stream-guard. It’s a zero-dependency circuit breaker that kills dangerous streams automatically: Timeouts: Stops hangs. Stall Detection: Kills idle connections. Heap Protection: Prevents OOM crashes. Byte Limits: Enforces strict size caps. Wrap any stream in one line. Stop the leaks. GitHub: https://lnkd.in/gvxvFUSB NPM: https://lnkd.in/g8ZpTxX5 #nodejs #javascript #backend #opensource #performance #typescript