When and when not to use Node.js - Node.js Basics [06] - Java Brains

in this tutorial I'm gonna address a very important topic and I'm gonna cover what are the situations where you want to use nodejs and what are the situations where it's not a good idea to use nodejs this is something that comes up in a lot of different discussions there are people who hate nodejs and they have their reasons but then i feel like a lot of the hate for node.js is a little misinformed no J's has a certain set of characteristics that are a little different from some of the other similar suicide application platforms so in this tutorial I'm going to cover then to use a node.js and then not to because of those characteristics of node.js specifically related to how threading and concurrency works with nodejs so here are the kind of problems that no js' really shines it right if you were to have these kind of problems in your applying nodejs you're building your applications in node.js you don't have a good time right so the kind of problems are if it's non blocking applications if it's event-driven if it's data intensive right fetching retrieving saving a lot of data or if it's IO intensive we're just kind of the same thing you have input output and you're waiting for an external system to do something and you're interacting with external systems and all that kind of stuff so this is where nodejs shines so in order to understand why this is so it's important to understand one important aspect of nodejs that it is single threaded okay what a single threaded mean it means that all the execution that happens in a node.js environment is carried out by one computer thread by one processing thread this is where a lot of people express shock and like what are you crazy just one processing thread that's gonna block everything else and all that stuff so this is very different from other similar programming platforms the rich are multi-threaded we have multiple threads operating at the same time okay that's not what happens in nodejs in nodejs you have a single thread and what it does is actually runs through a queue of events let's say you have something that needs to execute right you've written a function let's say you have written that equals B plus C right so there's some computation that needs to happen right it's nice to write B and C and put it to a so whatever those things are that needs to execute it gets queued up right there is a queue of events that happens and then that single processing thread just execute each and every event one by one in that queue okay so they execute this particular item done then it executes the next 110 and executes the next one right there are no two things that are happening in parallel so if you go to no js' and say hey I have this thing can you please execute it what does noj's do it says no there's a queue here go right in the back after I'm done executing all these things I'm gonna come to you wait this is have no J's works and the way it works is using this thing called the event loop the event loop is a kind of fundamental concept which is has very close ties to JavaScript right you see an event loop in a browser you also see an event loop in the nor J's platform it's basically this loop of execution where it's basically looking at this queue picking the event that's there executing it then picking the next one and any new event that comes up it goes way in the back of the queue to be executed all right so now isn't this a problem what if you have code that looks something like this right it's processor intensive takes a lot of time to compute write a bunch of lines which take a lot of time to compute well this is actually a problem with no J's if you have something like this it basically takes up that one application thread and it's doing this thing and nothing else works right it has everything else is to wait for this processor intensive piece of code to complete only then the next piece of code can execute all right this is a drawback you cannot do something like this by default there are ways in which you can do processor intensive stuff here but by default since there's one application thread if you do something like this you're just blocking that main application thread okay now this is the case you remember how I talked about nodejs is good for certain kinds of operations which is for example ir intensive and database retrieval kind of activities and all that kind of stuff well does take time to write it's not like you make any eye or call and get a result immediately it's not like you can fetch a database value immediately it's gonna take time for you to send the request and get back a response are you blocking that one single thread even there if so how the synergy is good in those scenarios imagine the situation you have this user on a browser and it makes a network call for example alright it's making a call to the server which is situated somewhere else and that server is slow let's say it takes five seconds to return a response now since it's a single thread does that thread certain read like it gets this event right and you'd say the benefit says that has instructions to go call the server it's calling the server it's taking a while is it waiting they're waiting for the response before it executes it's the next event and in that queue well no it doesn't doesn't do that because javascript is asynchronous right even in the browser as well as in the node.js platform it is any synchronous so typically when you're working in an environment like that the JavaScript runtime whether it be browser or the node.js environment the API that results in these kind of long running tasks for example making an HTTP request the API for making the HTTP request either in the browser or in the node.js environment he is an asynchronous API so when it makes a request it doesn't wait for the response okay it says okay I have sent out two requests I will deal with the response then I get it all right so it doesn't wait around so for example it immediately executes the next statement in your code and then then the response returns whenever it returns it's gonna deal with that at that point compare it with multi-threaded right in the case of a multi-threaded model when you have a platform which is multi-threaded you typically have something called a thread who have a bunch of threads it's not a single thread you have a bunch of threads and each thread does its thing so let's say you ask one of those threads to go execute something on a server I'd make a server call make an API call so that's straight it's gonna go make that call and then it's gonna read something else comes up another thread handles it like another piece of instruction another thread handles it and execute it and there are idols threads so as long as there are idle threads in the thread pool a new piece of instruction can be handled but then something is dependent on an external I or IDE maybe thinking a server call or maybe it's interfacing with some i/o it has to wait because it has to wait for the response to come back and that instruction has to return it responds to the next instruction right so thread pools that synchronous execution has this kind of a behavior right when there is an interface with an external system it waits so how is this different from the single threaded model in a single threaded module it cannot afford to read like this because if you have a single thread and it's waiting for something else to return a response you've essentially blott execution throughout right imagine you'd apply node.js on a server and then you have this kind of the behavior one user is trying to make it do something and it's waiting now it's locked at for everybody else right it's not gonna work so the way it works in a single threaded model is using something called callbacks so here's the idea when you make a network call once you have a piece of instruction which is okay I want to make this network call you don't wait for the network call to return what you do is you tell hey no js' I want to make this Network call after the network causes returned here is this event that needs to be executed right it gives that event that function to no js' and what node.js is gonna do is it's gonna say okay I'm gonna make that Network call and after the network call is done it's gonna take that event and put it to the queue okay so it's at this point it's gonna trigger the network call and then it's gonna move on to the next step the next event right it's not gonna hang around and wait like there's no waiting here it's gonna make the call one and then the network call returns back it says hey this guy asked me to execute this event after then it will call this done it's gonna take that event and put it at the back of the queue right it's gonna keep going it's not raining anymore so this is a synchronous operation so it's basically a callback marker all right so that's how single threaded operations work the key here is using callbacks we're gonna talk about callbacks a little bit later in the course but know that this is how nodejs operates it's a single threaded model it works with the concept of callbacks before we move on one thing that I'm gonna highlight is that when I say node.js is single threaded I'm referring to the application thread there was one main application thread and that is the single threaded model I'm talking about there are some people who say hey no no J's is actually not single thread that it's multi thread and all that stuff there are a bunch of things that they could be talking about there one is that your nodejs app sits on top of the runtime and the runtime is I believe implemented in C and C++ and all that other stuff and the runtime itself is not a node.js app and the right time could possibly be multi-threaded as a typical no james developer you don't worry about how the internals work if you make 10 different calls to 10 different api's potentially the internal implementation of those api's could be multi-threaded in the node.js runtime but as far as your application is concerned that part is single threaded except for the concept of worker threads again which I'm not going to cover in this course but as far as the main application thread is concerned that is single threaded I want to highlight that because that's something that's usually tends to confuse people up so this is a reason why these particular applications of node.js are really powerful that really shines here when you have non-blocking i/o right so let's say you're making a REST API call it's essentially non-blocking you're making a call you're not waiting around you had an event to the back of the cube when that return happens and you know what to do fit that so it's not blocking even driven is also the same thing so what used to block in a multi-threaded environment right you're making an external call waiting for I or waiting for something data intensive to return right waiting for an event to return what used to consume resources in a multi-threaded model is actually more efficient in node.js because it's not waiting around it's not consuming resources it just makes the call and moves along and when that returns says look I'll deal with you them all right so this is actually the reason why no js' is pretty powerful for these kind of applications it's actually more powerful than multi-threaded models let's say you have a thread pool of 10 threads and 10 of your events end up waiting for something else well you have a problem because the thread pool is full all the 10 threads that you have available are waiting the lement event cannot do anything it has to be however in the node.js module guess what happens you get hundred events which wait for an external thing all those hundred can just set and meet that because that single thread is gonna keep moving on it's not going to sit around and consume resources so these are the kind of applications where no J's really shines there's a drawback though and this is where you should not use node.js now what if you're working on an event which is not dependent on an external thing but instead it's compute-intensive right it has to do a lot of calculations that is where node.js really fails so let's say you have this function a commonly used example as you're writing a function which computes the Fibonacci number or the nth prime number which is computationally intensive right it's doing a lot of math doing a lot of calculations in that case no cheese cannot really say hey go do that thing and then it you know it moves on it's not even waiting it has to actually do the work it cannot pass on to the next event until it does the work because it's actually no js' which is doing the work in this particular case just hangs there it cannot even go to the next event right there's a single thread that single thread is blocked so these are the situations where nodejs is not good for right so you don't want to do data calculations you don't want to do processor intensive operations you're blocking operations because you don't want to block that single thread that exists in nodejs if you block it there's nothing else happening right so this is where you should not use no genius so the dissing mind there are certain applications which benefits from nodejs so web servers are a great example of things that are non blocking ideas you have a web server sitting there when the request comes in it does something with it it returns a response and then moves on right so this is where nodejs shines because it's an event-driven model right it's basically simulating that event queue that I talked about it's basically saying okay what's the event I'm gonna process this and then return a response if whatever you're processing requires an external dependency maybe it's calling the database maybe it's calling another API well guess what this thing is not sitting here consuming a thread it moves on and then you might have 10 requests a hundred requests which are all queued up and waiting for something else the hundred and first requests can still be handled by nodejs because it does not consume the thread pool with a waiting thread it uses the callback model so it's basically saying okay I'm gonna do this thing when I do this thing keep moving on keep accepting new events and handled it handles the response event there is an actual response right so web servers are a great example it also handles real time service this is a bit of a contra intuitive example you might say hey how can the real-time service be a good example of nodejs when I see real-time service I mean like like WebSocket connections where there is a continuous connection in place right you might say well how is that a good example because doesn't that consume the thread because you need that connection open all the time well no because the VAE nodejs handles this kind of concurrent connections is also using this asynchronous module so it manages a hundred concurrent connections by managing a single thread because again it uses this kind of like event-driven model when there is a concurrent connection that needs some execution it's only then that it pays attention to it and then it processes it as an event versus a multi-threaded model there a concurrent connection is actually consuming a thread have ten concurrent connections there is resources allocated to keeping those things concurrent right that's not there in the case of known node.js is also handy when you're building api's that are fronting no sequel databases when you don't have a schema and you have this kind of like a flexible object model node is great for that because javascript has there's a very good way of dealing with this kind of flexible object models pretty flexible the way you deal with objects so this is great example of using node.js as well you can also build command-line utilities which are also again even based right you run a command it does something and then it exists so that's also something that you can use node.js for but then again remember if you're using computationally intensive operations with the command line it's gonna hold up that one single thread so the command line user is essentially waiting which is the model of a command line anyway so it works fine no chase is very commonly used for build tooling specifically JavaScript the tooling you see a lot of like you're building on the single page application a lot of the single page application bill tolling is written using JavaScript because they are written by JavaScript developers so there's another common use case where no J's is used so these are some examples of where you should use node.js and where you should not use node.js and we've covered the asynchronous model of node.js and considerable detail in this tutorial so you can know why it is so alright so with this knowledge in 9 let's start writing node.js applications start writing our first node.js program in the next tutorial let's check it out you

Channel: Java Brains

Views: 288,667

Keywords: java, javascript, java brains, tutorial, brains, koushik, kaushik, brainbytes, explained, javascript tutorial, learn javascript, javascript tutorial for beginners, javascript programming tutorial, javascript programming, javascript programming for beginners, koushik kothagal, beginner, javascript training, nodejs tutorial, nodejs course, javascript nodejs tutorial, when to use node.js, when and when not to use node.js, node, when to use node, what is node js used for, what is node js

Id: UCd6LorxpkY

Length: 17min 35sec (1055 seconds)

Published: Tue Mar 24 2020