I am a web developer writing a lot of code in jquery.
I am trying to learn YUI3 and I notice the 'node' module there. I also heard about something called Node.js. Are the YUI3 node module and Node.js related ?
The official Node.js website does not seems to have much info.
What exactly is Node.js?
It is server-side does that mean we can used Node.js instead say PHP ?
What kind of applications are being developed using Node.js?
Is it worth for a web developer to invest time learning this ?
Node.js is actually a JavaScript framework for asynchronous servers. It runs server-side, rather than client-side like the YUI3 widgets library, and, chances are, if you don't need to roll your own high-performance evented sockets/asynchronous HTTP/etc. server and are just looking to write run-of-the-mill websites, then there is no need to learn Node.js.
(that said, Node.js is still pretty cool.)
Node.js is an evented I/O JavaScript server platform. It makes it relatively easy to create things like sockets and quickly handle many concurrent connections.
Node is similar in design to and influenced by systems like Ruby's Event Machine or Python's Twisted. Node takes the event model a bit further—it presents the event loop as a language construct instead of as a library. In other systems there is always a blocking call to start the event-loop. Typically one defines behavior through callbacks at the beginning of a script and at the end starts a server through a blocking call like EventMachine::run(). In Node there is no such start-the-event-loop call. Node simply enters the event loop after executing the input script. Node exits the event loop when there are no more callbacks to perform. This behavior is like browser javascript—the event loop is hidden from the user.
About Node.js
the biggest connection between YUI3 and node.js is yeti
a command-line tool for launching JavaScript unit tests in a browser and reporting the results without leaving your terminal.
Related
So, maybe this question is too noob and novice to be asked but I still have no clue why LIBUV got a place in Node JS Architecture? So here is my understanding of NodeJs architecture.
Node Js is built over V8
V8 is capable of running code written with EcmaScript standards.
V8 is written in C++.
So if you want to give any new functionality we can embed V8 in our C++ project and attach new code with new Embedded V8 in C++.
Now here is the doubt,
Since V8 supports EcmaScript Javascript that means it has the capability to run callbacks written with the standards of EcmaScript.
So we can add code for File System Access, HTTP server & DB access in C++ since there are libraries (header files) that gives that functionality since Java is written in C++ (correct me if I am wrong) and Java has the capability to do the same.
Now if we can add this functionality in C++ where does the place for Libuv come into the picture of NodeJs architecture.
Thanks in advance and
Happy Coding :)
Check the docs below -
https://nodejs.org/en/docs/meta/topics/dependencies/#libuv
Another important dependency is libuv, a C library that is used to
abstract non-blocking I/O operations to a consistent interface across
all supported platforms. It provides mechanisms to handle file system,
DNS, network, child processes, pipes, signal handling, polling and
streaming. It also includes a thread pool for offloading work for some
things that can't be done asynchronously at the operating system
level.
So to sum it up, V8 provides the functionalities related to running JS files, but to use system resources like Network, Files, etc., libuv is used. Also it provides a threading model for accessing the resources mentioned.
The libuv module has a responsibility that is relevant for some particular functions in the standard library. for SOME standard library function calls, the node C++ side and libuv decide to do expensive calculations outside of the event loop entirely.They make something called a thread pool that thread pool is a series of four threads that can be used for running computationally intensive tasks such as hashing functions.
By default libuv creates four threads in this thread pool. So that means that in addition to that thread used for the event loop there are four other threads that can be used to offload expensive calculations that need to occur inside of our application. Many of the functions include in the node standard library will automatically make use of this thread pool.
Now the presence of this thread pool is very significant. Well clearly Node.js is not truly single threaded
Libuv also gives node access to the operating system’s underlying file system such as networking. So just as the node standard library has some functions that make use of libuv thread pool it also has some functions that make use of code that is built into the underlying operating system through libuv.
Simple Http request
const https=require(“https”)
const start=Date.now()
https.request(“https://www.google.com”,res=>{
res.on(“data”,()=>{} )
res.on(“end”,()=>{console.log(Date.now()-start) }) }).end()
So in this case libuv sees that we are attempting to make an HTTP request. Neither libuv nor node has any code to handle all of this low level operations that are involved with a network request. Instead libuv delegates the request making to the underlying operating system. So it's actually our operating system that does the real HTTP request Libuv is used to issue the request and then it just waits on the operating system to emit a signal that some response has come back to the request. So because Libuv is delegating the work done to the operating system the operating system itself decides whether to make a new threat or not. Or just generally how to handle the entire process of making the request.
If anyone stumbles upon this and since it lacks a good answer to the OP's question, I will try to take on this.
TLDR;
Javascript language is not asynchronous
Javascript language is not multi-threaded
Callbacks themselves are not asynchronous, they are just mean to piggyback your code to an asynchronous operation.
Let's go over your doubts one by one.
1. Since V8 supports EcmaScript Javascript that means it has the capability to run callbacks written with the standards of EcmaScript.
Callbacks don't mean that the operation is asynchronous. A callback has got nothing to do with asynchronous execution. Callback is just a way to piggyback your function so that it executes after 'something asynchronous'.
// example of synchronous callback
function main(cb) {
console.log('main code of the function');
cb(); // callback invocation here
}
main(function () {
console.log('in callback');
});
Now an example of asynchronous callback
function getDataFromNetwork(url, cb) {
ajaxCall(url).then(cb);
}
getDataFromNetwork('http://some-endpoint', function (data) {
console.log(data);
});
This is an asynchronous call with a callback. Here getDataFromNetwork function is asynchronous not the callback. The point is that callbacks are just a mechanism of running a code after something. In an asynchronous operation, this becomes a necessity. How else we are going to do that? right?
No!
Nowadays we have async-await where you can run a code after the asynchronous function completes without using callbacks.
So you get that? Callbacks are not asynchronous. And that's not the point of having libuv.
2. So we can add code for File System Access, Http server & DB access in C++ since there are libraries (header files) that gives that functionality since Java is written in C++ (correct me if I am wrong) and Java has the capability to do the same.
Yes we can add lots of code for File System Access, Http server. But Why? We do already have a lot of libraries to do that. And yes its already written in C thats how NodeJS executes them.
Java already has that?
Right, but thats also a part of JVM rather than the core Java language, just like libuv is part of NodeJS runtime rather than the core Javascript language. In this regard both Java and NodeJS are similar. Its just that Java has its own C++ layer and NodeJS borrows libuv for that. BTW libuv was primarily built for NodeJS
3. Now if we can add these functionality in C++ where does the place for Libuv come in to the picture of NodeJs architecture.
I answered how these functionalities are already in C++, now lets see where libuv fits in this picture of the whole architecture.
Lets take an ajax/network call for example. Who do you think executes this?
NodeJS? No, It just gives instruction to its C++ API (Node API).
then is it Node API? No, It just gives instruction to the libuv
then is it libuv? Yes, it is
Same goes for timers, file access, child processes etc.
Also think when a lot of network calls, file access are fired within a NodeJS program, on what process it runs? who schedules them? who notify about the results and failure.
This is a lot to do. Java has its own thread pool to do that. Java has its own schedular to schedule the threads. and since Java provides threads to end user(programmers) as well. It makes sense to implement all that stuff using Java threads.
But NodeJS is single-threaded. Why it should have threads to execute I/O operations when it can borrow it from another library without making them a part of Javascript? After all, we aren't going to provide threads to the programmer so why bother?
Also Historically, Javascript was only meant to run in browsers. The only asynchronous operation browsers had access to were network requests, no file access, no DB. So we did not have a lot of bedrock already to build upon.
We have a Requirement to send Mass notifications from Server to multiple clients (around 500 Clients) at once. We have implemented Node.js but we are not sure what is the performance bottlenecks as Socket connection from all the Clients to the server is open all the times. We are using this for Java Web application
Please let us know if anybody has any exposure on this
Thanks sai
This question is impossible to answer in any detail as you have provided no details about your code, not to even mention any code example.
But from my experience when people have problems with concurrency using Node and they are below 10,000 concurrent connections which you should handle easily (see this answer) then the usual suspect is that they are using blocking function calls.
Are you using any blocking code in your app? If so then here's your problem. If you have any blocking code in your Node app (like calling functions with "Sync" in their name) then you will have serious problems with concurrency. You should never use blocking functions anywhere else than on the first tick of the event loop (and if you don't know what it means then you should never use them at all).
Also, since you write that you're using Node for Java Web application it can be more complicated than that. If your Node app is connecting to Java app that spawns a new thread for every connection then the bottleneck may be in your Java app and not your Node app. As you provide no details about our architecture, it's impossible to say. But one this is for sure: if you want to handle massive concurrency then you cannot use threads. You need to use event loops. There's a reason why nginx or Redis are single-threaded. Threads don't scale, especially for I/O-bound use cases. Profile your code and see if it's your Java or Node code that needs fixing.
This question already has answers here:
How to create threads in nodejs
(12 answers)
Closed 6 years ago.
Node.js multithreading.
Is it possible to use multithreading in Node.js? if yes.
What are the advantages and disadvantages of using multithreading in Node.js? Which are those modules that can be achieve multithreading in Node.js? I am a newbie to Node.js, I read from many blogs saying that Node.js is single threaded.
I know the java multithreading but I need to know whether it is possible in Node.js or not.
Yes and No. Let's start from the beginning. Why is NodeJs single-threaded, is explained here Why is Node.js single threaded?
While Node.js itself is multithreaded -- I/O and other such operations run from a thread pool -- JavaScript code executed by Node.js runs, for all practical purposes, in a single thread. This isn't a limitation of Node.js itself, but of the V8 JavaScript engine and of JavaScript implementations generally.
Node.js includes a native mechanism for clustering multiple Node.js processes, where each process runs on a separate core. But that clustering mechanism doesn't include any native routing logic or shared state between workers.
Generally and more clearly the statement is that, each node.js process is single threaded .if you want multiple threads, you have to have multiple processes as well.
For instance,you can use child process for this, which is described here http://nodejs.org/api/child_process.html . And just for your info, check out also this article, is very instructive and well written, and possibly will help you, if you want to work with child_processes -- https://blog.scottfrees.com/automating-a-c-program-from-a-node-js-web-app
Despite of all of the above, you can achieve a kind of multi-threading with C++ and native nodejs C++ development.
First of all check out these answers, probably they will help you,
How to create threads in nodejs
Node.js C++ addon: Multiple callbacks from different thread
Node.js C++ Addon: Threading
https://bravenewmethod.com/2011/03/30/callbacks-from-threaded-node-js-c-extension/
Of course you can find and leverage a lot of node plugins which are giving "multi"-threading capability: https://www.npmjs.com/search?q=thread
In addition, you can check JXCore https://github.com/jxcore/jxcore
JXCore is fork of Node.js and allows Node.js apps to run on multiple threads housed within the same process. So most probably JXCore is a solution for you.
"What are the advantages and disadvantages of using multi-threading in Node.js ?"
It depends of what you want to do. There are no disadvantages if you leverage and use Node.js sources correctly, and your "multi" - threaded plugins or processes or whatever, do not "hack" or misuse anything from the core of V8 or Node.js !
As in every answer, the correct answer is "use the right tools for the job".
Of course, since node is by design single-threaded, you can have better approaches for multithreading.
A technique that a lot of people use, is to make their multi-threaded application in C++, Java, Python e.t.c and then, they run it via automation and Node.js child_process (third-party application runs asynchronously with automation, you have better performance (e.g C++ app), and you can send input and get output in and from your Node.js application).
Disadvantages multi-threading Node.js
Check this: https://softwareengineering.stackexchange.com/questions/315454/what-are-the-drawbacks-of-making-a-multi-threaded-javascript-runtime-implementat
Keep in mind that if you want to create a pure multithreaded environment in Node.js by modifying it, I suppose that would be difficult, risky due to the complexity, moreover you have to be, always up to date with each new V8 or Node release that will probably affect this.
No, you can't use threads in node.js. It uses asynchronous model of code execution. Behind the asynchronous model, the node itself uses threads. But as far as I know, they can't be accessed in the app without additional libraries.
With the asynchronous model you don't actually need threads. Here is a simple example. Normally, in multi-threaded environments, you would run networks requests in each thread to not block the execution of code in main thread. With async model, those requests do not block the main thread and are still executed in other threads, only this is hidden from you to make development process straightforward.
Also check this comment by bazza.
Trying to understand using node.js for a web applications.
Are there basically 2 major uses cases, i.e.:
The entire system is written in node, so you have functions for login, logout, password recover, and whatever else the web app does. All of this is written in javascript?
You use node.js only for sending the client updates, to have a real-time effect on the app. But the rest of the application is written in e.g. rails or django
Please tell me if I understand this correctly:
In terms of other technologies used with node.js, you tend to see people using node.js as the backend server, socket.io on the client side to establish a cross-browser long running ajax call library, and then you might use backbone.js for your client mvc pattern.
Is this right?
Basically speaking, it is just a tool to run javascript code server side. What you do with it is up to you. Many are using it as a complementary system since it's relatively new, but it's perfectly possible to run an standalone app with node.js.
It's said to be particularly good at handling concurrent connections, which is why it is often recommended to handle real-time jobs within an app, but there is no "obligation" so to speak to use it for this specific use case, it's just one thing you can do.
As with everything, the best way to understand it is to use it, so don't be afraid to play around with it.
Use case for Node js as we are using in our Application
Skype like voice & video chat on chrome browser using node js
In Erlang I was able to immediately understand the notion of a 'node' - a self-contained Erlang VM. I could start a node on one machine with erl -name gandalf -setcookie abc, and another node on another machine (on the same LAN) with erl -name bilbo -setcookie abc. I could then spawn processes on gandalf which would communicate magically with other processes on bilbo. Now, since I also wanted to serve up a jazzy webpage with animated graphical results from my Erlang processes, I picked up some Javascript and learnt jQuery. Still a humble paduwan, but I sort of understand how Javascript fits into the scheme of things.
I recently came across node.js and an (evil) voice started whispering: 'This is it! Now you can do everything with Javascript! Forget Erlang and guards and periods, stick to a language that everyone uses'.
I've read the docs a bit, but I still don't understand what a node is in node.js. Do I have to run a http server and that becomes my node? What if I don't like http, or I don't care how gandalf talks to bilbo - that's what I like in Erlang. Maybe I nai:vely expect that node.js is erlang with Javascript sugar?
Node.js has much more in common with Twisted than Erlang/OTP. Node.js is just a single threaded SEDA event loop. Node.js has nothing compared to Erlang VM when it comes to distribution, hot code reloading, and scalability via processes, it isn't anything close to "Erlang with Javascript sugar"
Maybe because of your Erlang knowledge you thought that somehow Node.js had something to do with "nodes" (as erlang nodes), but it's just the name.
The main idea with Node.js is that you defer all expensive I/O operations and assign callbacks to the result of those operations. The reason is that I/O blocks the (only) process that is running at the moment. Node.js will handle this for you, given that you are coding in the proper way.
An easy example of this is a database call:
result = SQL.query("EXPENSIVE SELECT HERE")
doSomething(result);
moreStuff(); // This line must wait until the previous ones are completed.
In node you would code this in a very different way:
SQL.query("EXPENSIVE SELECT HERE", function(result) {
doSomething(result);
});
moreStuff(); // This line executes inmediately
If you have wrong code in your Node.js script, like:
while(true) { }
Then you are blocking the process and it won't be able to handle more requests than the current one, so in Node.js is mandatory to follow the above guidelines.
As I understand it, a Node.JS node is an instance of the V8 engine with the Node.JS runtime and event-loop running in it. While the Node.JS runtime gives you the ability to very quickly and simply begin processing HTTP requests, it's not mandatory; it is very good at handling most any kind of asynchronous I/O, really.
I don't know that much about Erlang, but my superficial understanding is that its great strength is high-concurrency computing. Node.JS doesn't specialize in that, per se. Its heart is "evented I/O", dealing neatly and cleanly with asynchronous I/O.
there is no "node" in node.js
as mentioned, when you run
node my_script.js
you are running one instance of V8 java script interpreter
(which is using one core for its lifetime).