what's faster async or sync ?
so I came across a video and it was talking about this article
https://www.softwareatscale.dev/p/the-hidden-performance-cost-of-nodejs#:~:text=NodeJS%20and%20GraphQL%20are%20popular,promises%2C%20which%20degrades%20request%20performance.
which says that the sync is a way faster approach than the promises/async and shows some tables showing the difference what would be the best approach since I always use async functions in serverless functions
The Hidden Performance Cost of NodeJS and GraphQL
NodeJS and GraphQL are popular technologies for building web applications, but in my experience, they come with certain scaling and performance tradeoffs to be aware of. tl;dr: GraphQL's modular structure generally leads to code that instantiates excessive promises, which degrades request performance. Benchmarks show a 2-3x latency increase.
9 Replies
Faster !== better (not necessarily)
The whole point of async is to fully take advantage of JavaScript's (since we're talking about JavaScript) event loop to continue to process further events while other long-running tasks continue to be worked on quietly in the background.
But as backend like nodejs handling database and stuff wouldn't be more useful to be faster?
Sure, if speed is the only concern. But in that case I'd argue there are better technologies you can reach for like Go or Rust.
Let me put it this way: unless you are sure that you need to optimize for speed, there's really not reason to do it from the get go.
This makes sense 👍
If you are using synchronous processing and 10 requests come at the same time, one request will be processed faster while the other 9, sequentally, are waiting.
Would node be best option for backend If the project is large or would it be better with other framework and languages like c#.net
The gains shown in that benchmark are not that impressive to be honest. Plus, if in the sync request there's some other bottleneck in the database, network latency, etc., that will the entire Node.js process to stop working entirely. You are risking the entire server to stop to a halt to a lot of external conditions that may be out of your control.
You should use what you or your team already knows. If you don't have any evidence that the server is the bottleneck when it comes to performance there's no reason to make the switch for something else for no reason.
Great, i was just really thinking about it to know as programmer for the future and what would be best stuff to do / to learn
bit of a silly article
the problem isn't async per se, the solution was to make fewer graphql calls which...yeah ofc that is the solution, to a problem you created
you can't avoid async code, if something needs to be async there is nothing you can do to avoid it, what you can do is limit how many times you query for something, it's like sending messages on discord and waiting for the other party to respond before saying anything else instead of just saying everything you have to say in one message
how large or small a project is doesn't determine the language you use, instead you have to know what is it that you're looking to accomplish and what are the challenges
node is really good for I/O stuff but if what you need isn't I/O speed but rather more CPU related like processing a lot of data then you wouldn't use node