Node.js is a serious thing now… (2023)

over the years I've found that node.js is kind of strange in the world of back-end development let's say you wrote some code for a back-end API server and you deploy that code to a machine with four gigs of memory and two CPUs then you start receiving traffic to your server over the internet now this is a node.js server which means well what does that mean first of all node.js is not a programming language JavaScript is the language and typescript gets transpiled down to JavaScript also node.js is not a server there are plenty of general purpose apps built with node.js that have nothing to do with servers node.js is a JavaScript runtime environment it's a thing that executes JavaScript outside of the browser and most of the time we use it to build back-end applications and so since our app is written in JavaScript that means it's a single threaded application it can only utilize one CPU at a time which is a big waste of resources this is why we typically run multiple node.js processes each server running on a different port and for that to work we have to use a load balancer like nginx pm2 is a process manager kubernetes is a container manager and then Heroku and Amazon are Cloud platforms but all of these are solutions to the load balancer problem now what's interesting is that if we we chose just about any other mainstream language then we can use true multi-threading meaning your application running on a single process can utilize all of the CPUs on the machine and also threads are a lot lighter than processes they're faster to spin up and they take up less memory ultimately making your application a lot more efficient so it's kind of a bummer that in order to achieve maximum performance with node.js you have to spin up multiple processes or at least that's what I thought until recently alright ladies and gentlemen so it turns out that there is a way to achieve multi-threading with node.js but I think I should demonstrate first why you would even want to use multi-threading when we have an asynchronous runtime right node.js is async you'd already handle concurrent requests so what do you need multi-threading for so here I have a little demo I have a Fibonacci function then I have this thing called do FIB which is just wrapping the Fibonacci function inside of a promise and the goal is to make this Fibonacci function asynchron furnace and make it so that we can evoke it multiple times concurrently of course if you have enough experience with node you know that we can't do this but we're going to try it anyway here I have promise.all and I'm running do FIB 10 times hopefully concurrently then I'm going to print all the values and let's go ahead and see what happens here so let's go ahead and run this okay so we can see it is evoking the function a few times so we see that each individual time it evoked the function it took about 470 milliseconds and in the end it took about 4.7 seconds to get it all done so obviously it didn't actually execute all of these concurrently it actually did it one at a time it did it synchronously why because in JavaScript you can't just take a synchronous function and then wrap it in an async promise and expect it to magically become async so this is ultimately the big problem with single threading is if you do any CPU intensive calculations it's going to block the entire event Loop which in turn is going to block your entire app and that's especially bad in a server environment okay so this time around we're going to do the same demo except we're going to use worker threads instead so we have our do FIB function and so inside of this do FIB function we're saying worker use new worker we're going to execute fib.js and pass in some arbitrary very parameters there we're going to say once we receive a message from the worker we're going to log that and then resolve the promise and once we receive an error we're going to reject the promise and this is how fib.js looks so we have our Fibonacci function here we're getting the result and we're saying parent Port dot post message and so this is going to send the data from the worker back up to the parent and so in terms of the main logic we're doing promise.all with do FIB 10 times same as before and remember before it did all of these synchronously did them one at a time what we're hoping is that this is going to evoke these all concurrently instead so let's run the code and see what happens okay boom that was fast so it took about one second for each worker to complete everything was done in about 900 milliseconds as well so this suggests that these did not evoke one at a time sequentially no they evoked all concurrently and we know that these all evoked on a different thread of execution because it didn't block the entire app so there you go that's proof that worker threads do actually create new threads and this is not the same as using Fork because when you Fork a process that's creating a whole new child process which has a lot of memory overhead it's also very slow to spin those up if you try to spin up a bunch of processes on the Fly it's not gonna be very performant so this is pretty awesome the fact that we do have true multi-threading now the API is a little bit funny right passing messages around and all that but it's not really that unusual nowadays message passing is kind of a popular way of doing multi-threading so one of the issues with using worker threads is that it's a little bit different than traditional multi-threading with worker threads each thread runs in its own context it has its own block of memory let's say you have a one or two gigabyte buffer of memory and you want to pass that to a worker thread and then perform some Transformations and then pass it back to the main thread that's a lot of data transfer especially in a server environment so what you generally want to do with performance is not necessarily copy the data around but rather pass ownership of data around you want to share memory between threads and fortunately there is a way to do that with worker threads and so here what we've done is create a shared buffer and what we're going to do is fill this buffer with five and so five five five five and then we're going to create a worker and we're going to pass in that shared buffer to the worker the worker is w dot JS right and then once we get a message from the buffer we're going to go ahead and print that buffer ultimately the goal here is that this w dot JS file should to mutate the buffer directly without needing to copy it around so here with w dot JS we have the buffer and we grab the shared buffer from the worker data that was passed in from the parent and then now we're going to mutate that buffer and we're not going to pass the data back to the parent we're just going to tell the parent that we're done if this works this is the ultimate evidence that we're not actually copying data around but we're able to mutate it between two different threads so the goal is that by the time we get down here the buffer should be 7777 so it should have started off as 55555 we passed the shared buffer to the worker then afterwards is 7777 so let's see if this works so do it and boom buffer before modify 5555 buffer after modify 7777 so this is undisputable proof that we can indeed share a buffer of memory between threads without needing to copy that buffer around and this is a really great thing when it comes to Performance let's say you want to spin off some worker threads to resize images create thumbnails or convert PDF files or there's a lot of things you might want to do and fortunately we can do those in a very efficient way so there you go ladies and gentlemen kind of crazy right JavaScript is single threaded but with worker threads we can achieve multi-threading and we can do it in a relatively efficient way yes we've always had web workers on the front end but to be able to do this stuff on the back end is kind of a new thing and I think it is kind of a game changer I don't think it's necessarily going to replace other languages like go and rust and whatnot but nonetheless for folks who are already using node.js in their stack this is just another tool to help achieve higher performance so hey if you like the video please like And subscribe support a little YouTuber like myself and thank you for watching

Channel: Code With Ryan

Views: 217,308

Keywords:

Id: _Im4_3Z1NxQ

Length: 8min 17sec (497 seconds)

Published: Mon May 29 2023

Reddit Comments

[u/AnasThasio]

we need prime to react on this