71
The future of back-end development
(lemm.ee)
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev
Thousands of requests per minute can mean many things so maybe you're referring to several hundred requests per minute, but one of our services at work gets 300 requests/second which is ~18K requests per minute and it's really not that much. We're using pretty cheap cloud services. Even thrice the traffic is pretty much a slow walk for your average production-grade web framework.
Web frameworks are built to support an insane amount of incoming requests, including node. The issue with node is the single threading and having to scale with worker threads AFAIK.
edit: our runtime is C#
People always say this but its not technically correct and can be misleading.
Technically, JavaScript runs single threaded but not Node.js itself and certainly not when using it on the backend in something like Express. IO operations and other things tooling libraries do can cause you to run out of a thread pool. But Node.js, when handling requests, gives you much of the benefit of multithreading without having to deal with multithreaded code.
Aaaahh so libuv actually runs a thread pool, TIL. I'm another victim of internet propaganda I guess ๐ . You know, I never actually checked libuv docs until now and they seem quite welt built.
The silliest thing I've just realized is that I knew that the first implementation of a web server in dotnet core was using libuv, and I still didn't think twice about the single threaded meme.