"Turn" Why should I use node. js? The case of each introduction

Translated from: http://blog.jobbole.com/53736/

Introduced

The popularity of JavaScript has changed so much that the way it is being used for web development today has become quite different. Just like in the browser, we can now run JavaScript on the server, spanning from the front to the back, which is unimaginable because JavaScript is like a Flash or Java applet just a few years ago. That way, embedding the Web page runs in a sandbox environment.

Before you dive into node. js, you may need to read and understand the benefits of using cross-stack JavaScript (JavaScript across the stack), which unifies the programming language and data Format (JSON), allowing you to best reuse developer resources. Since this is more about JavaScript, it's not too much to discuss here. But it's really a key advantage of using Node in the development process.

As Wikipedia says: "Node. js is a wrapper shell for the Google V8 engine, the LIBUV platform abstraction layer, and the core library that the subject uses Javscript to write. "Beyond that, it's worth noting that the goal of the author of node. js, Ryan Dar Ryan Dahl, is to create a site with real-time push capabilities. In node. js, he gives developers an excellent solution for asynchronous development using event-driven. (Note: V8 is the fastest Javascript parsing engine developed by Google, and Libuv is an open source, custom-built cross-platform asynchronous IO Library for Node.) ）

In short: node. JS uses WebSocket-based push technology on real-time web applications. What kind of revolution does that mean? Well, after more than 20 years of stateless interaction based on a stateless request-back mechanism, we finally have a real-time, two-way connected Web application where both the client and server can initiate communication and can freely exchange data. In stark contrast to this is the traditional Web response pattern, where clients are always actively initiating communications and the server is passively returning. In addition, these are based on open Web Components (HTML, CSS, and JS) that run on standard 80 ports.

Some might say that we've been using Flash and Java applets in the form of many years--but in fact, these are just ways to use the network to pass data to the sandbox environment on the client. They are all run in isolation and often operate to non-standard ports that require additional permissions.

With its unique advantages, node. JS now plays a key role in the products of many well-known companies.

In this article, we will discuss not only how these benefits are achieved, but also why you use node. js to replace some of the classic Web application models.

How does node. js work?

The main idea of node. JS is to use non-blocking, event-driven I/O operations to maintain the lightness and efficiency of processing cross-platform (across distributed devices) data-intensive real-time applications. It sounds a bit around the mouth.

What it really means is that node. js is not a silver-bullet platform that will dominate the world of web development. Instead, it is a platform to meet special needs. You certainly don't want to use node. js to do CPU-intensive operations. In fact, using it for heavy computing is tantamount to discarding almost all of the benefits of Node. Node's real highlight is building high-performance, highly scalable Internet applications-because it handles massive and high-throughput concurrent connections.

How it works is quite interesting. The traditional Network Service technology, is each new connection (request) will generate a new thread, this new thread will occupy the system memory, will eventually take up all the available memory. While node. JS is only running in one single thread, using non-blocking asynchronous I/O calls, all connections are handled by the thread, and under LIBUV, it is allowed to support tens of thousands of concurrent connections (all hanging in the thread's event loop).

To do a simple calculation: if it is a normal web program, the new access to a connection will consume 2M of memory, when running on a system with 8GB RAM, the cost of context switching between the threads, the maximum theoretical value for concurrent connections is 4,000. This is the case with traditional Web server technology. node. JS achieves an extension of about 1M for a concurrent connection (related certifications).

Of course, there is also a problem when all client requests share a single thread, which is also a potential flaw in writing a node. js application. First, a large number of calculations can cause the single thread of Node to temporarily lose its response, causing all requests from other clients to block until the end of the calculation is resumed. Second, developers need to be very careful not to let a Exception block the core's event loops, as this will cause the node. JS instance to terminate (in effect, the program crashes). (I note: If a page in PHP will not affect the site to run, but Nodejs is a thread to process all the links, so whether the card is calculated or is blocked by an exception may affect all other links.) The solution is discussed later. ）

The way to avoid breaking the process when an exception is thrown is to pass the exception using callbacks (rather than throwing them, as in other environments). Even if some unhandled exceptions block the program, there are still a number of solutions that can be used to monitor the Node process to perform the necessary post-crash recovery efforts (although you will not be able to restore the user's Session), most commonly using the Forever module, or use other external system tools such as upstart and Monit.

Npm:the Node Package Manager

When we talk about node. js, a place that should never be overlooked is the default built-in module management tool,--NPM. It is inspired by the Ruby Gems (with versioning and dependency management capabilities, which allows easy installation of reusable component management tools through an online repository).

A complete list of common modules can be found on the NPM website (https:://npmjs.org/), or by using the NPM CLI tool installed with node. js. The ecosystem of the module is open to everyone and anyone can publish their own modules, all of which can be found in the NPM repository. You can find a brief introduction to NPM on the HTTP://HOWTONODE.ORG/INTRODUCTION-TO-NPM page (a bit old but still visible).

Some of the NPM modules that are currently popular are:

• Express–express.js, a simple and flexible node. JS Web application framework, is now the standard framework for most node. js applications, and you can already see it in many of the node. JS Books.
• Connect–connect is a node. JS HTTP Service Extension framework that provides a high-performance "plug-in" collection, known as middleware, and is one of the basic parts of Express.
• Socket.io and sockjs– are currently the most popular two websocket components on the service side.
• jade– is one of the popular template engines and is the default template engine for Express.js. It is inspired by HAML.
• MONGO and mongojs– encapsulate a variety of MongoDB APIs, but I usually work with the mongoose is also recommended.
• The Redis–redis client function library.
• The Coffee-script–coffeescript compiler allows developers to use coffee to write their node. JS program.
• Underscore (Lodash, lazy) – the most popular JavaScript ToolPak, a package for node. JS, and two peers who take a slightly different approach to achieving better performance.
• forever– is probably the most popular tool for ensuring that the node script continues to run.

There are a lot of good modules, not listed here (I hope no offense to the list).

where node. js should be used to chat

Chatting is the most typical application of multi-user real-time interaction. Starting with IRC, there are many open source or open source protocols running on non-standard ports, and now using node. JS can solve these problems-run WebSockets on standard port 80.

The chat application is the best example of the advantages of node. JS: Lightweight, high-traffic, and good for running-intensive data on cross-platform devices (albeit with low computational power). At the same time, chatting is a very worthwhile use case because it is simple and covers most of the solutions that a typical node. js will use so far.

Let's try to describe how it works.

In the simplest case, we set up a chat room on our website, users can send messages on the above, of course, a one-to-many form. For example, suppose a total of three people are connected to our website.

On the side of the service side, we have a simple site using Express.js, the site to achieve two things 1) processing path to '/' GET request, issued including a message board and a send message of the ' Send ' button page 2) a listener client to send a new message WebSocket S service.

On the client side, we have an HTML page with a two JS method, one for triggering the event "send" button, which will send the input message through Webscoket, another method is to use Webscoket on the client to listen to the server on the push (for example, Messages sent by other users).

When a client sends a message, the thing that happens is:

1. On the browser, clicking the Send button triggers the JS function to send the text in the input box through the WebSocket message to the server's WebSocket client (which is connected when the page is initialized).
2. The WebSocket component on the server receives the message and then forwards it to all other connected clients through the broadcast method.
3. With the WebSocket client component running on the page, all clients can receive this push new message. Then the JS processing function can add this message to the text box.

This is one of the simplest examples. If you want a better solution, you can use a Redis database to make a simple cache. In a more advanced solution, you might need a message route that specifically handles Message Queuing and requires a more robust sending mechanism, such as overwriting a user who is temporarily offline when sending, or storing a message for an offline registered user that has not yet been received, and so on. But no matter what improvements you have made, node. JS will follow a basic principle: respond to events, handle multiple concurrent connections, and maintain a fluid user experience.

Object Database Interface (API on TOP of a object DB)

Although node. js is really good at interacting with real-time applications, it's also great for querying data (such as MongoDB) through the object Database (objects db). Data stored in JSON format allows node. js to process directly without the need to tangle with data transformations and matching issues.

For example, if you're using Rails, you'll turn the JSON data into a binary model, and when the data is Backbone.js, angular.js or jQuery AJAX calls back to JSON. If it is Nodejs, you can simply export the JSON object for use by a client through a REST API. Also, you don't have to worry about formatting problems between JSON and any data if you use MongoDB when you read and write from the database. In short, you can avoid multiple data conversion issues, whether on the client side, on the server, or on the database.

Queue input

If you are receiving a high volume of concurrent data, your database may become a bottleneck for your processing. As described above, node. JS can easily handle concurrent connections. However, because database operations are a blocking operation (in this case), this is where the trouble is. The solution for node. JS is to acknowledge that the client's data is real before the data is actually written.

In this way, the system continues to maintain its response at high loads, which is especially useful when the client does not need to strictly verify that a data is successfully written. Typical examples include logging or logging of user-traced data (user-tracking), which is processed in batches and later used, and also includes final consistency (so, commonly used in NoSQL) acceptable, and actions that do not require immediate response (such as Facebook The number of likes on the update).

The data enters the queue through certain caches, or the underlying components of Message Queuing (such as RabbitMQ, ZeroMQ), and is digested one by one through a separate database bulk write process, or through a more performant compute-intensive backend service. Other languages/frameworks can also achieve similar operations, but in the same configuration is not up to nodejs high throughput and high concurrency.

Simply put: With Node, you can throw database operations aside and process them later, assuming they succeed and continue. (The author notes: In the development of the usual situation is usually, a time-consuming operation through the callback function asynchronous processing, the main thread continues to execute down)

Data flow

On more traditional web platforms, HTTP requests and responses are more like isolated events, but in fact they are data streams. This observation can be used to build some cool features on the Nodejs. Because data is received in the form of streams, we can process the files that are being uploaded online on the website. In this way, real-time audio and video encoding can be implemented, as well as code between different data sources (see Proxy for the next paragraph).

(I note: Node has to replace the webserver such as Apache processing data, so developers can directly receive the client a copy of the uploaded data, and real-time processing. The above paragraph sounds a bit abstract, but you can simply imagine that do not need to open YY or QQ, open the Web page can be used for voice video functions. ）

Agent

node. JS can handle a large number of concurrent connections asynchronously, so it is easy to use as a proxy on the server side. This is especially useful when brokering between different services with different response times, or when collecting data from multiple sources.

For example, consider a server-side application and third-party resources to communicate to update data from different sources, or to store some of the image and video resources on the service side to the third party cloud service.

Although the dedicated proxy server does exist, if you do not have a dedicated proxy server, or if you need a locally developed solution, using Node as an agent can be a better choice. In terms of this solution, I mean when you're developing, you can use node. JS's development environment to build a service to handle requests for resources and proxies, and in a production environment, you can use dedicated proxy services (such as nginx,haproxy, etc.) to handle these interactions.

Instrument panel for Stock trader

Let's go ahead and discuss the application piece. Real-time Network solutions can easily implement securities trading software-to track the price of stocks, perform calculations, do technical analysis, and generate reports.

The use of a real-time web-based solution will allow the trader to easily switch between the working software and the work place. We'll probably see them on the beach in Florida State, Ibiza or Bali soon, I'm sure.

Application Monitor Panel table

Another common use case where using Node+web+socket is ideal: tracking site visitors and visualizing real-time interactions between them in real time. (If you are interested, you can go to see Hummingbird)

You may need to capture the real-time status of your users, or even when they reach a specific point in the channel, open an AC channel and move to the next stage through a targeted interaction presentation. (If you are interested, I recommend you look at Canddi)

Imagine if you knew the real-time operation of your visitors and were able to visualize their interactions, which would be a great boost to your business. With real-time, two-way socket communication for node. JS, now you can do it.

System Monitoring Instrument

Now, let's look at the infrastructure aspects of things. Imagine, for example, a SaaS operator who wants to provide its users with service monitoring pages (for example, status pages on GitHub). With the event loop of node. js, we can create a powerful Web-based dashboard that asynchronously checks the status of the service and uses the WebSockets to push the data to the client.

This technology enables real-time escalation of internal (intra-company) and public service status. Let's take this idea a little farther, and try to imagine a monitoring application for the Network Operations Center (NOC) in a telecom operator, a cloud/network/server operator, or some financial institution, all running on this application made up of node. js and WebSocket, not Java and/or Java Applet.

Note: Do not attempt to use Node to create a hard system (that is, a system with a consistent response time requirement). Erlang is probably a better choice for this type of application.

Where can I use the node. JS Service-side WEB app

Using Express.js with node. JS can also be used to create a typical Web application on the server side. However, while it is possible, it is not the most typical use case to render HTML using node. js to make request + response forms. There was support for and opposition to the practice. Here are some ideas for reference:

Advantages:

• If you don't need CPU-intensive computing, you can use Javascript to develop from start to finish, even from databases such as MongoDB. This significantly reduces the development process (including cost).
• For a single page application or WebSocket application that uses node. js as a server, crawlers can receive a full HTML rendering response, which is more SEO-friendly.

Disadvantages:

• Any CPU-intensive computation will hinder the response of node. js, so using a multithreaded platform is a better approach. Alternatively, you can also try to scale out the calculation [*].
• node. JS is still suffering with relational databases (see below). Please, if you want to perform relational data operations, consider other environments: Rails, Django, or even ASP.

Another solution is to establish a highly extensible MQ-supported environment and back-end processing for these CPU-intensive computations to keep Node as a receptionist to handle client requests asynchronously.

where node. js should not use a server-side WEB app that uses a relational database

Compare Express.js and Ruby on Rails in node. js, and when you use a relational database, don't hesitate to choose the latter.

node. JS's relational database tool is still in its early stages and is not yet mature enough to allow people to use it happily. At the same time, rails inherently comes with data access components, along with the DB Schema Migration support tool and some gems (pun, one of these treasure-like tools, the Ruby Gems package). Rails and its partner frameworks have the implementation of a very mature and proven activity log (active record) or data Mapper data access layer, which is something you would want to use when you use pure JavaScript to replicate these apps.

However, if you are really inclined to use JS all (and be prepared for possible madness), continue to focus on sequelize and Node ORM2, although the two are still immature, but they will eventually catch up.

It is entirely possible and not uncommon to use Node light as the front-end and Rails as the backend to connect to the relational database. (I note: There is a kind of argument, PHP this kind of programmer can also be counted as the front end)

Heavy service-side calculation and processing

When it comes to a lot of calculations, node. JS is not the best solution. You certainly don't want to use node. js to build a Fibonacci number calculation service. In general, any CPU-intensive operation can weaken the throughput advantage of node through event-driven, asynchronous I/O models, because any incoming requests will be blocked when a thread is taken up by a high computational amount that is not asynchronous.

As previously mentioned, node. JS is single-threaded and uses only a single CPU core. As for the multi-core concurrency processing on the server, Node's core team has done some work on this in the form of the cluster module (reference: http://nodejs.org/api/cluster.html). Of course, you can also easily run multiple node. JS server instances through Nginx's reverse proxy to avoid a single thread blocking problem.

With regard to clustering (clustering), you should transfer all the heavy computations to a more appropriate language-written background process, while allowing them to communicate through Message Queuing servers like RabbitMQ.

Even if your background processing might not have the advantage of initially running on the same server, this approach has the potential to be highly scalable. These background processing services can be easily split out as separate worker servers without the need to configure the load on the portal Web server.

Of course, you can also use the same method on other language platforms, but with node. js you can get very high throughput, and each request is handled very quickly and efficiently as a small task, as we have already discussed.

Conclusion

We have discussed node. js from theory to practice, from its goals and ambitions, to its strengths and weaknesses. In node. JS Development, 99% of the problems are caused by misuse of blocking operations.

Keep in mind that node. JS was never created to solve large-scale computing problems. It was designed to solve large-scale I/O problems and did very well at this point.

In summary, if your project requirements do not include CPU-intensive operations and do not require access to any blocked resources, then you can take advantage of the advantages of node. js to enjoy fast, scalable network applications.

"Go" Why should I use node. js? case-by-section