Hi
Great article and I already watched your YouTube video some days ago.
Here's my doubt.
According to ur 2nd point , Worker threads/ child process can only process synchronous logic.
But bcrypt module is an asynchronous task
These 2 statements looks to me contradictory
In my opinion, he write the bcryptHash function using async await statement, it mean the return from that function not a promise again, so the process was changed to synchronous. CMIIW.
hmm,
but in my opinion, i think if any function that surrounded by ASYNC statement would always return the promise, no matter if it's really asynchronous or not.
I think you miss some statement, not offending your opinion but if you write await on the body function that wrapped with async statement, the return will synchronus. You can check on this link javascript.info/async-await#await, with example showAvatar function.
I give an example, on the first picture, the variable githubUser using await statement to retrieve the value from fetch, it will return the actual value that send by the server.
On the second picture, the return was Promise that we knew it asynchronous. The value can be fulfilled or rejected and need chained function to process the result.
Hi there thank you very much for watching and for the comment.
So, with my 2nd point...take note that I used the "bcryptjs", and not the well known "bcrypt" module, which would get offloaded to the libuv thread-pool because it runs on the OS level. "bcryptjs" is purposely designed to be written completely in JavaScript and to be synchronous, because it's actually a security feature to hash passwords synchronously and cause the delay.
I hope that clears up my 2nd point? Below is from their NPM Docs:
"While bcrypt.js is compatible to the C++ bcrypt binding, it is written in pure JavaScript and thus slower (about 30%), effectively reducing the number of iterations that can be processed in an equal time span."
yes, it makes all sense now.
Thanks for your efforts,
But I wonder what kind of such huge computational tasks exists especially on DB operations from Node.js programs so that I could use these techniques to improve the performance w.r.t to DB operations
Always a pleasure. Most of the time it's going to come to advanced business logic that needs to perform a series of processes on returned data from DB or 3rd party queries, etc.
What you always want to be doing is keeping the primary thread and event loop spinning as fast as it can and processing those incoming requests. The moment you have tasks that contain synchronous logic that cause even the slightest of delays, hand it over to Worker Pool 👍.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi
Great article and I already watched your YouTube video some days ago.
Here's my doubt.
According to ur 2nd point , Worker threads/ child process can only process synchronous logic.
But bcrypt module is an asynchronous task
These 2 statements looks to me contradictory
In my opinion, he write the bcryptHash function using async await statement, it mean the return from that function not a promise again, so the process was changed to synchronous. CMIIW.
hmm,
but in my opinion, i think if any function that surrounded by ASYNC statement would always return the promise, no matter if it's really asynchronous or not.
I think you miss some statement, not offending your opinion but if you write await on the body function that wrapped with async statement, the return will synchronus. You can check on this link javascript.info/async-await#await, with example showAvatar function.
First Picture
Second Picture
I give an example, on the first picture, the variable githubUser using await statement to retrieve the value from fetch, it will return the actual value that send by the server.
On the second picture, the return was Promise that we knew it asynchronous. The value can be fulfilled or rejected and need chained function to process the result.
I understand your point, it's definitely returning resolved value or rejected value.
Hi there thank you very much for watching and for the comment.
So, with my 2nd point...take note that I used the "bcryptjs", and not the well known "bcrypt" module, which would get offloaded to the libuv thread-pool because it runs on the OS level. "bcryptjs" is purposely designed to be written completely in JavaScript and to be synchronous, because it's actually a security feature to hash passwords synchronously and cause the delay.
I hope that clears up my 2nd point? Below is from their NPM Docs:
"While bcrypt.js is compatible to the C++ bcrypt binding, it is written in pure JavaScript and thus slower (about 30%), effectively reducing the number of iterations that can be processed in an equal time span."
yes, it makes all sense now.
Thanks for your efforts,
But I wonder what kind of such huge computational tasks exists especially on DB operations from Node.js programs so that I could use these techniques to improve the performance w.r.t to DB operations
Always a pleasure. Most of the time it's going to come to advanced business logic that needs to perform a series of processes on returned data from DB or 3rd party queries, etc.
What you always want to be doing is keeping the primary thread and event loop spinning as fast as it can and processing those incoming requests. The moment you have tasks that contain synchronous logic that cause even the slightest of delays, hand it over to Worker Pool 👍.