ASAman Singhinamanksinghin.hashnode.dev·Jul 24 · 6 min readNode.js Error Handling: Operational vs Programmer ErrorsError handling is where a lot of Node.js applications quietly fall apart. Not with a dramatic crash — with a request that hangs forever because a rejected Promise went unhandled, or a process that die00
ASAman Singhinamanksinghin.hashnode.dev·Jul 24 · 6 min readNode.js Memory Leaks and Profiling: Finding What Holds MemoryA Node.js memory leak rarely announces itself. The service runs fine in testing, ships, and then over hours or days its memory creeps up until it hits the limit and the process is killed and restarted00
ASAman Singhinamanksinghin.hashnode.dev·Jul 24 · 6 min readScaling Node.js with the Cluster Module: Using All Your CoresA single Node.js process uses a single CPU core. Your server has eight. Out of the box, seven of them sit idle while one does all the work — which means a default Node deployment leaves most of the ma00
ASAman Singhinamanksinghin.hashnode.dev·Jul 24 · 6 min readNode.js Worker Threads: Moving CPU Work Off the Main ThreadNode.js is superb at I/O and helpless at CPU-bound work on the main thread — a direct consequence of the single-threaded event loop. The moment your code has to do something genuinely computational — 00
ASAman Singhinamanksinghin.hashnode.dev·Jul 24 · 6 min readNode.js Streams and Backpressure: Processing Data Without Running Out of MemoryThe difference between a Node service that handles a 2 GB file on a 512 MB server and one that crashes trying is almost always streams. The naive approach reads the whole thing into memory, does somet00