Quick calculation: Assuming that each thread requires 2 MB of memory, running on a system with 8 GB of memory can theoretically have up to 4000 concurrent connections (Calculation from Michael Abernethy's article "Just what is Node .js?", published on IBM developerWorks in 2011; unfortunately, the link to this article is now dead), and this does not include the cost of context switching between threads . This is the scenario you typically deal with in traditional web server technology. By avoiding all these issues, Node.js achieves levels of over 1M concurrent connections, and 600k concurrent websockets connections.
Of course, a potential pitfall of writing Node.js applications is the problem of sharing a single thread between client requests. First, heavy computations can block a Node's single thread and cause all clients problems (more on this later), since incoming requests will be blocked until the computation is complete. Secondly, developers need to be very careful not to let exceptions bubble up to the core (top-most) Node.js event loop, which will cause the Node.js instance to terminate (program crash).
To avoid exceptions from bubbling up to the top level, a common technique is to pass errors back to the caller as callback parameters (rather than throwing them as in other environments). Even if some unhandled exception bubbles up to the top level, there are tools to monitor the Node.js process and perform the necessary recovery from crashes (although recovery to the current state of the user session may not be possible), most commonly Forever Module.
npm: node package manager
One thing that definitely shouldn’t be overlooked when discussing Node.js is the support for package management using the built-in npm tool, by default every Node.js environment will be installed. The concept of npm modules is very similar to Ruby Gems: a set of reusable components that can be easily installed through an online repository, with version and dependency management.
The complete list of packaged modules can be found on the npm website or can be accessed using the npm CLI tool that is automatically installed with Node.js. The module ecosystem is open to everyone, anyone can publish their own modules and the published modules will appear in the npm repository. For an introduction to npm, see the Beginner's Guide, and the npm Publishing Tutorial's section on publishing modules.
Some useful npm modules are:
-
express - Express.js, a Node.js web development framework inspired by Sinatra, popular nowadays The de facto standard for most Node.js applications.
-
hapi - A modular and very easy-to-use configuration-centric framework for building web and service applications
-
connect —— Connect is an extensible HTTP server framework for Node.js, which provides a series of high-performance "plug-ins" called middleware as the basis of Express.
-
socket.io and sockjs – the two most common websockets server-side components today.
-
pug (formerly Jade) – One of the popular templating engines inspired by HAML, the default option in Express.js.
-
mongodb and mongojs – MongoDB wrappers that provide an API for the MongoDB object database in Node.js.
-
redis —— Redis client.
-
forever - Probably the most commonly used utility to ensure that a given node script runs continuously. Keep Node.js processes in a production state when encountering unexpected failures.
-
bluebird —— Full-featured Promises/A implementation with excellent performance
-
moment —— For parsing, validation, operation and formatting A lightweight JavaScript date library that converts dates.
The list keeps growing. There are many useful packages out there for everyone to use.
Which occasions should use Node.js
Online chat
Online chat is the most typical real-time multi-user application and the best case of Node.js: it is a lightweight , high-traffic, data-intensive (but low processing and computation) applications that run distributedly across devices. It's also a great study case because it's simple but covers most of the paradigms you'd use in a typical Node.js program.
Let's try to picture how it works.
Assume the simplest scenario, there is a chat room on our website, people can exchange messages in a one-to-many (actually to everyone) way.
On the server side, we have a simple Express.js program that implements two things: 1) a GET request handler, which provides a message board and user interface The functionality of the "Send" button for initializing new message input, and 2) the websockets server for listening for new messages from websocket clients.
On the client side, we have an HTML page with several handlers set up, one for the click event of the "Send" button, which receives the input message and sends it to the websocket, and another with Used to listen for new incoming messages and display them on the websockets client (i.e. messages sent by other users that the server wants the client to display).
When one of the clients posts a message, the following happens:
- The browser captures the click of the "Send" button event handler JavaScript program, from the input field (i.e. the message text) Get the value in and send out a websocket message using a websocket client connected to our server (initialized when the web page is initialized).
- The server-side component of the websocket connection receives the message and forwards it to all other clients using broadcasting.
- All clients receive new messages through the websockets client component running in the web page. They then update the page by adding new messages to it.
This is the simplest example. For a more robust solution, you can use a simple Redis-based cache. Or in a more advanced solution, a message queue can be used as a message route, and a more powerful delivery mechanism can be implemented, such as storing messages when the connection is lost or the client is offline. But no matter what improvements you make, Node.js will still run on the same basic principles: react to events, handle many concurrent connections, and keep the user experience smooth.
API on top of object database
While Node.js is certainly great for developing real-time applications, it is also great for exposing data from object databases such as MongoDB. JSON stored data allows Node.js to work well with objects that are consistent with the stored data and without data conversion.
For example, if you are using Rails, then you need to convert from JSON to binary models, and then convert them to JSON over HTTP for use in React.js or Angular.js, or even with simple jQuery AJAX calls. With Node.js, you can directly expose your JSON objects for client consumption via a REST API. Additionally, you don't need to worry about converting between JSON and anything else when reading from or writing to the database (if you're using MongoDB). In short, using a unified data serialization format in the client, server and database can avoid the trouble of multiple conversions.
Queue Input
If you receive a lot of concurrent data, your database may become a bottleneck. As mentioned above, Node.js can easily handle concurrent connections on its own. But because database access is a blocking operation (in this case), we run into trouble. The solution is to confirm the client's behavior before the data is actually written to the database.
With this approach, the system can maintain its responsiveness under high load, which is especially useful when the client does not need to confirm that the data was successfully written. Typical examples include: batching when logging or writing user tracking data; and Eventual consistency (often used in the NoSQL world) Acceptable operations that do not require immediate reflection (such as updating Facebook "Likes" count).
Data is queued through some kind of cache or message queue (e.g., RabbitMQ, ZeroMQ) and passed through a separate batch write process to the database, or digested by a compute-intensive backend service and written to better A platform capable of performing such tasks. Similar behavior can be implemented in other languages or frameworks, but not on the same hardware to maintain the same high throughput.
In short: using Node, you can write database writes to one place and process them later as if they had been successfully processed.
Data flow
In more traditional web platforms, HTTP requests and responses are viewed as isolated events, when in fact they are streams. You can use this property in Node.js to build some cool functionality. For example, files can be uploaded and processed at the same time. Because the data comes in through the stream, we can process it in real time. This can be used for real-time audio and video encoding, as well as proxying between different data sources (see next section).
Proxy
It's easy to use Node.js as a server-side proxy that can handle large numbers of concurrent connections in a non-blocking manner. This is particularly useful for proxies for multiple services with different response times, or for scenarios where data is collected from multiple sources.
For example, the following scenario: When the server-side program communicates with third-party resources, it will extract data from different sources, or store resources such as images and videos on third-party cloud services.
Although there are dedicated proxy servers, if you don't have an underlying proxy infrastructure, or you need a local development environment, Node may be helpful to you.
Stock Trader’s Data Interface
Let’s go back to the application. Another example that can be easily replaced with a real-time web solution is a stockbroker's trading software, which is used to track stock prices, perform calculations, technical analysis, and create charts.
Brokers will be able to easily switch workstations or workplaces if they switch to a live, web-based solution. Soon, we may start seeing them on Florida beaches...
Application Monitoring Dashboard
Another common use case where Node-with-web -socket is perfect for: tracking website visitors and providing real-time visualization of their interactions. You can collect statistics from your users in real time and even open communication channels and engage in targeted interactions with your visitors by targeting them at specific points in the funnel. This can be found here: CANDDi.
Imagine if you could understand what your visitors were doing in real time, how would you improve your business? You can now do that by using Node.js’ real-time bidirectional sockets.
System Monitoring Dashboard
In terms of infrastructure,. For example, a SaaS provider who wants to provide a service monitoring page to its users (for example, GitHub Status Page). With the Node.js event loop, we can create a powerful web-based dashboard that asynchronously checks the status of the service and uses websockets to push data to the client. The status of both internal companies and public services can be reported in real time using this technology.
Note: Do not try to build hard real-time systems (i.e. systems that require consistent response times) in Node.js. For that kind of application, Erlang may be a better choice.
Where can I use Node.js
Server-side Web application
Node.js with Express.js can also create classic Web applications on the server side. There are supporters and opponents of this approach. Here are some issues to consider:
Advantages:
- If your program does not have any CPU-intensive calculations, you can build it with Javascript and an object storage database such as MongoDB, It's even possible to build at the database level. This significantly simplifies development work.
- The crawler receives a fully rendered HTML response, which is better for SEO than single page applications or websockets applications running on Node.js.
Disadvantages:
- Any CPU-intensive calculation will prevent Node.js from being responsive, so a threaded platform is a better approach.
- Using Node.js with relational databases is still very difficult (more details below). If you're working with a relational database, choose another environment such as Rails, Django, or ASP.Net MVC.
An alternative to CPU-intensive computing is to create a highly scalable MQ-enabled environment with back-end processing capabilities to make Node a front-end "staffer", and handle client requests asynchronously.
When not to use Node.js
Server-side web applications with relational databases
For example, combining Node.js Express.js with Ruby on Rails, the latter is clearly more appropriate when it comes to relational data access.
Compared to its competitors, Node.js's relational database tools are still quite primitive. Rails, on the other hand, provides out-of-the-box data access setup and database schema migration support tools, in addition to other Gems. Rails and similar frameworks have mature and proven Active Record or Data Mapper data access layer implementations, and if you want to try to replicate these features in pure JavaScript, then good luck to you good luck.
However, if you really prefer to implement everything in JS, check out Sequelize and Node ORM2.
If you are just using Node.js as a public-facing interface while using a Rails backend to access a relational database, this is fine and not uncommon.
Heavy server-side calculations and processing
Node.js is not the best platform when it comes to heavy calculations. You definitely don't want to use Node.js to build a Fibonacci calculation server. Typically, any CPU-intensive operation will negate any throughput benefits provided by Node through the event-driven, non-blocking I/O model, since any incoming requests will be blocked while the thread is occupied by number crunching.
As mentioned earlier, Node.js is single-threaded and uses only one CPU core. When it comes to adding concurrency on multi-core servers, the Node core team has done some work in the form of the cluster module. You can also easily run several Node.js server instances behind a reverse proxy nginx.
If using a cluster, you should still put all the heavy calculations into background processes written in a more suitable environment, and have them communicate through a message queue server like RabbitMQ.
This approach has the potential to achieve very high scalability even though all your background processing may initially run on the same server. These background processing services can be easily distributed to separate worker servers without the need to configure the front-end web server load.
Of course, you can use the same approach on other platforms, but with Node.js, you get the high reqs/sec throughput we talked about because each request is a very fast and efficient small tasks.
Conclusion
We discussed Node.js from theory to practice, starting with its goals and ambitions, and ending with its best points and pitfalls. When people encounter problems with Node, it almost always comes down to blocking operations being the root of all evil - 99% of which are directly caused by misuse of Node. Remember: Don’t use Node.js to solve compute scaling problems. It was designed to solve I/O scaling problems, and it
did it really well. So, if your application does not contain CPU-intensive operations and does not access any blocking resources, you can take advantage of Node.js and enjoy fast, scalable web applications.
Original English address: https://medium.com/the-node-js-collection/why-the-hell-would-you-use-node-js-4b053b94ab8e
【Video tutorial recommendation:
nodejs video tutorial】
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
