this post was submitted on 25 Aug 2023
66 points (94.6% liked)
Programming
17326 readers
238 users here now
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
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Yeah, JavaScript/TS doesn't get a great rep being used on the backend. But I use it on quite a few of my projects, one of which gets thousands of requests per minute. I was skeptical of whether or not using Node on the backend would hold up, but the performance has been stellar.. pretty surprising, actually.
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.