node. JS Profile II

Event-based Web applications
Traditional Web Form submission is a typical event-based pattern. In other words, a lot of data is entered in the Web form (the user enters the text box, selects the check box, selects some items from the list, and so on), and then submits the data to the server. This scenario is actually a single program event: the form data is submitted using the Post method.   This is how AJAX-based Web applications work. Send large amounts of data at once
For Ajax, it is possible to have a little relationship with event-based programming. Some interactions between the client and server side can be considered event-based. A typical scenario is to enter a provincial code that sends a request to the server to get the city and province name. Ajax here through XMLHttpRequest does not need to throw a lot of data to the server at once. But this does not change the way most Web applications are based on the current state of the page refresh model. Ajax has been used more extensively for many interesting visual-related interactions, with quick forms validation and no flush submission data, so you can avoid re-loading pages.   Therefore, although a real post request has not been initiated by submitting the table forms, the Post form submission can be simulated via Ajax. Frankly speaking, this traditional way of Ajax interaction also hinders the innovation of AJAX programmers. Each time a request is sent (no matter how small the requested data), it will go back and forth through the network. The server must respond to this request, usually to open up a new process. Therefore, if you are actually developing in an environment of an event model, you may need to maintain a connection between your page and the server by initiating 10 to 15 separate small requests, and the server will create 10 to 15 threads (possibly less, depending on the policy that the server allocates the thread pool when it processes new requests). When this number is multiplied by 1000 or 10000 or 100000 (for each page that requires 10 requests, the more users access the page, the more requests are made), the problems of memory overflow, conflict caused by logical interleaving, network paralysis, system crashes.

As a result, in most scenarios, web apps need to maintain a minimal dependency on events. One tradeoff is that the response of the server-side program is not a small piece of data, but rather a packet with more redundancy data structures, usually JSON data, when the eval () problem is encountered. The problem is, of course, in Eval (), but it is also closely related to the web itself and the server-line program, including the HTTP request and response strategy (at least in this scenario) between the page and the server.
Perhaps some people disagree with the above question, because you know there are many ways to avoid the problems caused by direct eval (), and you will use such as Json.parse () instead of Eval (). There are also many compelling arguments that encourage us to use eval () carefully. These things are worthy of further discussion. But anyway, if you look at eval () brings too many problems like stack overflow (stack Overflow), you'll find that most programmers don't use eval () correctly or safely. This is indeed a problem. Because too many novice programmers don't seem to realize how bad the eval () problem is.
Send a small amount of data continuously
Node brings new ideas for architecting applications, and we can use the event model to architect Web applications, or "small" event models, based on node. In other words, you should send a large number of requests based on a large number of events, each with small packets of data, or fetching small amounts of data from the background as needed, rather than sending very few requests, with a large amount of data per request. In many scenarios, you will need to wake up GUI programs in most cases (Java swing Programmer's GUI knowledge reserve can be useful). Therefore, when the user enters the first and last name and then the next input box, a request is made to verify that the user name entered is already present. The same is true for verification of provincial and municipal codes, addresses, and phone numbers. Each occurrence of an event on the page produces a request and a response.
What difference does it have? Why is node able to do this and circumvent existing threading issues? In fact, node is not so mysterious, node website fully explained its philosophy:
Node's goal is to provide a solution for building scalable Web applications, in the Hello World example, where the server can handle many client connections at the same time. Node has a convention with the operating system, and if a new link is created, the operating system notifies node and then goes into hibernation.   If someone creates a new link, it (Node) executes a callback and each link takes up a very small (memory) stack overhead. Node is non-blocking and does not appear to rival threads (node is very happy with instant requests, what happens, let him happen), and when new requests arrive at the server, there is no need to do anything for this request alone. Node is just sitting there waiting for a leisurely (please

Request, and requests are processed. It can be implemented with very simple code without spending the programmer's precious effort to implement a full set of server-side logic.

Yes, chaos is inevitable.
It is worth mentioning that the problems posed by non-blocking systems also occur in this programming pattern: a process (non-threading) waits for a data store operation, which results in another operation to fetch irrelevant data. This unexpected operation has an impact on the existing wait: the author means that multiple operations occur at the same time or do not occur in a predetermined order, causing confusion, i.e. the operation itself is not atomic. Note, however, that most event-based web programming patterns are "read-only"! You've probably never had a "micro-request" to modify data, or very rarely. In contrast, it is common to verify data legitimacy and query data through such requests. In this case, it is best to respond directly to the request. The database itself will be locked operation, generally speaking, an excellent database can be effectively locking unlock data operations, without the server-side program code to do more. And node is more efficient than the maintenance and release of the operating system processing threads, so that the server does not have to separate a process for "web response".
In addition, node plans to implement process forking, and the HTML5 Web Workers API provides engine (spec) support for more complex process controls. Similarly, if you are using an event-based model to architect a Web application, your program may have at least 100 more scenarios that require threading support.   Eventually you will find that your programming ideas and the way you think about them have changed, and your attention will be placed on the logic of the server-side processing requests without caring about how node works. Where node comes in
Here we discuss another Web development model, whether it's using node or not using event-based programming patterns, which doesn't matter, because it's so important. In short: the remedy!   In summary, there are different solutions for different issues, regardless of whether the solution solves other problems. Thinking stereotype
Not only in the field of web design, but in all programming there is some kind of mindset. You can describe this mindset: the more you learn, the more you know, the more problems you can solve, and the more applications you have in your skills. This may seem natural, unless you delve deeper into the technology. Yes, learning new languages and new tools and using them extensively is not always a bad thing. But often goes into a misunderstanding, that is, because you understand it, so you use it, not because you have mastered the skills and tools that are "best suited" to your business.

Let's look at Ajax and there's too much talk about Ajax. We know that Ajax provides a reliable solution for fast query requests that are not refreshed. Today, because of the misuse of Ajax, it is too much to replace the traditional form submission. We come across a new technology, learn it, master it, apply it, and then "abuse it." After all, many business scenarios require only traditional form submissions, without the need for Ajax. As simple as it is, there are literally thousands of cases of abuse of Ajax, just because the developer of an application is blindly respecting Ajax.
In the same vein, node also faces a problem. When you first recognize node and discover its benefits, you want to use it. Will be a brain of the PHP or Perl program into node. The result? It sucks. You've already got OCD, and you're always trying to use node in a scenario that's not designed for you: using JavaScript to submit a lot of data to node, or to a lot of JSON data that's returned to JavaScript by node, to the front end for Eval (), Or simply use node as a file server to return an HTML page or do an HTTP redirect.
But these scenes are not what node is good at. node is better at handling small requests and event-based I/O, using node to resolve rapid communication between clients and servers, sending large amounts of data to the server using form submissions, and using PHP and Perl to handle heavy database operations and the generation of Dynamic HTML pages. Use node to run on the server side to handle a small volume of requests. Whether you're using rails or spring and a variety of service-side containers, just get on demand.   Be sure to understand what the problem you need to solve, and take the best solution based on it, instead of solving the problem based on the skills you are currently mastering. The simple purpose of node
The last thing to note is that when you're getting deeper into your programming, you'll find that you don't have to be proficient in every tool, API, and framework you use. Use the knife on the blade, not the hammer as a drill. Learn about the scenarios and issues that each tool applies to, and then find the most appropriate scenario for the tool. If you want to become a superhuman generalist (programmers often want to know everything), you are far from the "experts", so-called experts, that is, in one or two areas to achieve a very proficient. Of course, every boss wants to find a Superman-like generalist, but this kind of person often can not be asked.
Learning node can be a bit difficult, but it's worth it. Why? Because you're looking for a solution for JavaScript-based Web applications. This means that your existing JavaScript programming skills are not lost, and when you need to use PHP or Perl, you have to re-learn a new language, and node doesn't have to do that. Learning new languages brings more problems than learning them.
The challenge of learning node is that you need to be more active, split the program into small, low-coupling fragments, and assemble them as if you were assembling an array. But node and event-based I/O do not solve all the problems, but to be sure, many of the key issues can only be solved by node.

node. JS Profile II