深入学习Node.js：服务器端JavaScript革命

需积分: 50 167 浏览量更新于2024-07-23 收藏 7.4MB PDF 举报

"这篇资料是关于Node.js的基础教程，适合初学者学习，涵盖了Node.js的基本概念和使用方法。" Node.js是一种基于Chrome V8引擎的JavaScript运行环境，它允许开发者在服务器端使用JavaScript进行编程。由于JavaScript在客户端的广泛使用，Node.js的出现使得前后端开发可以使用同一门语言，大大提高了开发效率。尽管JavaScript在浏览器环境下有着严格的同源策略和其他安全措施，但在Node.js中，由于运行在服务器端，这些限制不再适用，开发者需要更加注意安全问题。 Node.js的核心特性包括事件驱动、非阻塞I/O模型，这使得它在处理高并发请求时表现出色。Node.js的模块系统是其另一个亮点，通过`require`函数，开发者可以方便地引入和使用各种功能模块。在Node.js生态系统中，npm（Node Package Manager）是世界上最大的开源库生态系统，提供了丰富的第三方模块，涵盖了从HTTP服务器到数据库接口的各种需求。在学习Node.js时，首先需要理解它是如何利用JavaScript的异步编程模型来实现高性能的。在浏览器环境中，JavaScript是单线程的，但在Node.js中，通过事件循环和回调函数，可以处理多个并发任务，避免了传统的多线程同步操作带来的复杂性。此外，Node.js的流（Stream）API是处理数据流的重要工具，它能够高效地处理大文件和网络数据。 Node.js的另一大特色是其内置的HTTP服务器库，这使得创建Web服务变得极其简单。通过Node.js，你可以轻松构建RESTful API或者全栈Web应用。同时，Node.js也可以与各种数据库进行集成，如MongoDB、MySQL等，通过ORM（对象关系映射）库如Sequelize或Mongoose，简化数据库操作。学习Node.js的过程中，理解模块系统（CommonJS）和包管理器（npm）的工作原理非常重要。CommonJS提供了一种标准来组织代码，而npm则让开发者可以方便地分享和复用代码。同时，了解如何使用调试工具以及如何处理错误和异常也是必不可少的技能。总结来说，Node.js是基于JavaScript的服务器端技术，它的易学性和强大的性能使其成为现代Web开发的重要工具。然而，由于其服务器端的特性，开发者需要掌握一些不同于前端开发的安全和性能优化知识。通过深入学习Node.js，你将能够构建可扩展的、高性能的网络应用。

Consider how the typical web server works, such as Apache. Apache has two different approaches to how it

handles incoming requests. The first is to assign each request to a separate process until the request is

satisfied; the second is to spawn a separate thread for each request.

The first approach (known as the prefork Multi-Processing Model, or MPM) can create as many child

processes as specified in an Apache configuration file. The advantage to creating a separate process is that

applications accessed via the request, such as a PHP application, don't have to be thread safe. The

disadvantage is that each process is memory intensive, and doesn't scale very well.

The second approach (known as the worker MPM), implements a hybrid process-thread approach. Each

incoming request is handled via a new thread. It's more efficient from a memory perspective, but also

requires that all applications be thread safe. Though the popular web language PHP is now thread safe,

there's no guarantee all the many different libraries used with PHP are thread safe.

Regardless of approach used, both types respond to requests in parallel. If five people access a web

application at the exact same time, and the server is set up accordingly, the web server handles all five

requests simultaneously.

Node does things differently. What happens is that when you start a Node application, it's created on a

single thread of execution. It sits there, content, waiting for someone to come along and make a request.

When it gets a request, no other request can be processed until it's finished processing the code for the

current request.

You might be thinking that this doesn't sound very efficient, and it wouldn't be except for one thing: Node

operates asynchronously, via an event loop and callback functions. An event loop is nothing more than

functionality that basically polls for specific events and invokes event handlers at the proper time. In Node,

a callback function is this event handler.

Unlike other single threaded applications, when you make a request to a Node application and it must, in

turn, make some request of resources (such as a database request or file access), Node processes the

request, but doesn't wait around until the request receives a response. Instead, it attaches a callback function

to the request. When whatever has been requested is ready (or finished), an event is emitted to that effect,

triggering the associated callback function to do something with either the results of the requested action, or

the resources requested.

If five people access an application at the exact same time, and the application needs to access a resource

from a file, Node attaches a callback function to a response event for each request. As the resource

becomes available for each, in turn, the callback function is called, and each person's request is satisfied. In

the meantime, the Node application can be processing other requests, either for the same people, or

different people.

Though it doesn't process the requests in parallel, depending on how busy the application is, and how it's

designed, most people usually won't perceive any delay in the response. Best of all, the application is very

frugal with memory and other limited resources.

Reading a File Asynchronously

To demonstrate the asynchronous nature of Node, Example 1-2 is a modification of the Hello World

application from earlier in the chapter. Instead of just typing out "Hello, World!", it actually opens up the

previously created helloworld.js, and outputs the contents to the client.

Example 1-2. Asynchronously opening and writing out contents of a file

// load http module

var http = require('http');

var fs = require('fs');

// create http server

http.createServer(function (req, res) {

// open and read in helloworld.js

fs.readFile('helloworld.js', 'utf8', function(err, data) {

www.it-ebooks.info

res.writeHead(200, {'Content-Type': 'text/plain'});

if (err)

res.write('Could not find or open file for reading\n');

else

// if no error, write JS file to client

res.write(data);

res.end();

});

}).listen(8124, function() { console.log('bound to port 8124');});

console.log('Server running on 8124/');

A new module, File System (fs), is used in this example. The File System module wraps standard POSIX

file functionality, including opening up and accessing the contents from a file. The method used is

readFile. In the example, it's passed the name of the file to open, the encoding, and an anonymous

function.

The two instances of asynchronous behavior I want to point out in Example 1-2 are the callback function

that's attached to the readFile method, and the callback function attached to the listen method.

As discussed earlier, the listen method tells the HTTP server object to begin listening for connections

on the given port. Node doesn't block, waiting for the connection to be established, so if we need to do

something once the connection is established, we provide a callback function, as shown in Example 1-2.

When the connection is established, a listening event is emitted, which then invokes the callback

function—outputting a message to the console.

The second, more important callback instance is the one attached to readFile. Accessing a file is a time

consuming operation, relatively speaking, and a single threaded application accessed by multiple clients

that blocked on file access would soon bog down and be unusable.

Instead, the file is opened and the contents read asynchronously. Only when the contents have been read

into the data buffer—or an error occurs during the process—is the callback function passed to the

readFile method called. It's passed the error, if any, and the data if no error occurs.

In the callback function, the error is checked, and if there is no error, the data is then written out to the

response back to the client.

A Closer Look at Asynchronous Program Flow

Most people who have developed with JavaScript have done so in client applications, meant to be run by

one person at a time in a browser. Using JavaScript in the server may seem odd. Creating a JavaScript

application accessed by multiple people at the same time may seem even odder.

Our job is made easier because of the Node event loop, and being able to put our trust in asynchronous

function calls. However, we're no longer in Kansas, Dorothy—we are developing for a different

environment.

To demonstrate the differences in this new environment, I created two new applications: one as a service,

and one to test the new service. Example 1-3 shows the code for the service application.

In the code, a function is called, synchronously, to write out numbers from 1 to 100. Then a file is opened,

similar to what happened in Example 1-2, but this time the name of the file is passed in as a query string

parameter. In addition. the file is opened only after a timer event.

Example 1-3. New service that prints out a sequence of numbers, and then the contents of a file

var http = require('http');

var fs = require('fs');

www.it-ebooks.info

// write out numbers

function writeNumbers(res) {

var counter = 0;

// increment global, write to client

for (var i = 0; i<100; i++) {

counter++;

res.write(counter.toString() + '\n');

}

// create http server

http.createServer(function (req, res) {

var query = require('url').parse(req.url).query;

var app = require('querystring').parse(query).file + ".txt";

// content header

res.writeHead(200, {'Content-Type': 'text/plain'});

// write out numbers

writeNumbers(res);

// timer to open file and read contents

setTimeout(function() {

console.log('opening ' + app);

// open and read in file contents

fs.readFile(app, 'utf8', function(err, data) {

if (err)

res.write('Could not find or open file for reading\n');

else {

res.write(data);

}

// reponse is done

res.end();

});

},2000);

}).listen(8124);

console.log('Server running at 8124/');

The loop to print out the numbers is used to delay the application, similar to what could happen if you

performed a computationally intensive process and then blocked until the process was finished. The

setTimeout function is another asynchronous function, which in turn evokes a second asynchronous

function: readFile. The application combines both asynchronous and synchronous function calls.

Create a text file named main.txt, containing any text you want. Running the application and accessing the

page from Chrome with a query string of file=main generates the following console output:

Server running at 8124/

opening main.txt

opening undefined.txt

The first two lines are expected. The first is the result of running console.log at the end of the

application, and the next line is a print out of the file being opened...but undefined.txt?

When processing a web request from a browser, be aware that browsers may send more than one request.

For instance, a browser may also send a second request, looking for a favicon.ico. Because of this, when

you're processing the query string, you must check for to see if the data you need is being provided, and

ignore requests without the data.

www.it-ebooks.info

That the browser sends multiple requests can impact on your application if you're

expecting values via a query string. You must adjust your application, accordingly. And

yes, you'll still need to test your application with several different browsers.

So far, all we've done is test our Node applications from a browser. This isn't really putting much stress into

the "asynchronous" nature of the Node application.

Example 1-4 contains the code for a very simple test application. All it does is use the http module to

request the example server several times in a loop. The requests aren't asynchronous. However, we'll also

be accessing the service using the browser as we run the test program. Both, combined, asynchronously test

the application.

I'll cover creating asynchronous testing applications in Chapter 14, "Testing and

Debugging Node Applications"

Example 1-4. Simple application to call the new Node application 2000 times

var http = require('http');

//The url we want, plus the path and options we need

var options = {

host: 'localhost',

port: 8124,

path: '/?file=secondary',

method: 'GET'

};

var processPublicTimeline = function(response) {

// finished? ok, write the data to a file

console.log('finished request');

};

for (var i = 0; i < 2000; i++) {

// make the request, and then end it, to close the connection

http.request(options, processPublicTimeline).end();

}

Create the second text file, named secondary.txt. Put whatever you wish in it, but make the contents

obviously different from main.txt.

After making sure the Node application is running, start the test application:

node test.js

As the test application is running, access the application using your browser. If you look at the console

messages being output by the application, you'll see it process both your manual and the test application's

automated requests. Yet the results are consistently what we would expect, a web page with:

• the numbers 1 through 100 printed out

• the contents of the text file, in this case main.txt.

Now, let's mix things up a bit. In Example 1-3 make the counter global rather than local to the loop

function, and start the application again. Then run the test program and access the page in the browser.

The results have definitely changed. Rather than the numbers starting at 1 and going to 100, they start at

numbers like 2601 and 26301. They still print out the next sequential 99 numbers, but the starting value is

different.

The reason why is, of course, the use of the global counter. Since you're accessing the same application

in the browser, as the test program is doing automatically, you're both updating counter. Both the

manual and automated application requests are processed, in turn, so there's no contention for the shared

data (a major problem with thread safety in a multi-threaded environment), but if you're expecting a

consistent beginning value, you might be surprised.

www.it-ebooks.info

Now change the application again, but this time remove the var keyword in front of the app variable—

'accidentally' making it a global variable. We all have, from time to time, forgotten the var keyword with

our client-side JavaScript applications. The only time we get bit by this mistake is if any libraries we're

using are using the same variable name.

Run the test application and access the Node service in your browser a couple of times. As you'll

immediately see, Node is not your ordinary JavaScript.

When coding for Node, var is your friend.

Benefits of Node

By now you have a working Node installation—possibly even a couple.

You've also had a chance to create a couple of Node applications, and test out the differences between

synchronous and asynchronous code (and what happens if you accidentally forget the var keyword).

Node isn't all asynchronous function calls. Some objects may provide both synchronous and asynchronous

versions of the same function. However, Node works best when you use asynchronous coding, as much as

possible.

The Node event loop and callback functions have two major benefits.

First, the application can easily scale, since a single thread of execution doesn't have an enormous amount

of overhead. If we were to create a PHP application similar to the Node application in Example 1-3, the

user would see the same page—but your system would definitely notice the difference. If you ran the PHP

application in Apache with the default prefork MPM, each time the application was requested, it would

have to be handled in a separate child process. Chances are, unless you have a significantly loaded system,

you'll only be able to run—at most—a couple of hundred child processes in parallel. More than that number

of requests means that a client needs to wait for a response.

A second benefit to Node is that you minimize resource usage, but without having to resort to multi-

threaded development. In other words: you don't have to create a thread-safe application. If you've ever

developed a thread-safe application previously, you're probably feeling profoundly glad at this statement.

However, as was demonstrated in the last example application, you also aren't developing JavaScript

applications for single users to run in the browser, either. When you work with asynchronous applications,

you need to make sure that you don't build in dependencies on one asynchronous function call finishing

ahead of another, because there are no guarantees—not unless you call the second function call within the

code of the first. In addition, global variables are extremely hazardous in Node, as is forgetting the var

keyword.

Still, these are issues we can work with—especially considering the benefits of Node's low resource

requirements and not having to worry about threads.

A final reason for liking Node? You can code in JavaScript without having to worry

about IE6.

www.it-ebooks.info

剩余281页未读，继续阅读

abcsddwere

粉丝: 0
资源: 1

深入学习Node.js：服务器端JavaScript革命

node.js资料

node.js相关资料

node.js教学资料。

Node.js 10、Node.js 12、Node.js14、Node.js16、Node.js18各版本使用到的glibc最低版本

客户端未安装node.js打开node.js的网页是不是比未安装node.js打开速度要快

客户端未安装node.js打开node.js的网页是不是比未安装node.js打开速度要慢

安装了node.js，怎么装node.js Runtime

html怎么调用node.js,javascript – 在HTML中使用Node.js模块

Node.js 15.11.0对比Node.js 12.18.3

shell脚本判断node.js是否存在并安装相应版本的node.js

最新资源