Node.js introductory tutorial mini book, complete example of node.js introductory web application development_Basic knowledge

console.log("Hello World");

node helloworld.js

var http = require("http");

http.createServer(function(request, response) {
response.writeHead(200, {"Content-Type": "text/plain"});
response.write("Hello World") ;
response.end();
}).listen(8888);

var http = require("http");

var server = http.createServer();
server.listen(8888);

function say(word) {
console.log(word);
}

function execute(someFunction, value) {
someFunction(value);
}

function execute(someFunction, value) {
someFunction(value);
}

var http = require("http");

http.createServer(function(request, response) {
response.writeHead(200, {"Content-Type": "text/plain"});
response.write("Hello World") ;
response.end();
}).listen(8888);

var http = require("http");

function onRequest(request, response) {
response.writeHead(200, {"Content-Type": "text/plain"});
response.write("Hello World");
response.end();
}

http.createServer(onRequest).listen(8888);

var http = require("http ");

function onRequest(request, response) {
console.log("Request received.");
response.writeHead(200, {"Content-Type": "text/plain"});
response.write("Hello World");
response.end();
}

http.createServer(onRequest).listen(8888);

console.log("Server has started.");

var http = require("http") ;

...

http.createServer(...);

var foo = require("http");

...

foo.createServer(...);

var http = require("http");

function start() {
function onRequest(request, response) {
console.log("Request received.");
response.writeHead(200, {"Content-Type": " text/plain"});
response.write("Hello World");
response.end();
}

http.createServer(onRequest).listen(8888);
console.log("Server has started.");
}

exports.start = start;

var server = require("./server");

server.start();

node index.js

🎜> url.parse(string).pathname |

> http://localhost:8888/start?foo=bar&hello=world
                                                                                        
querystring(string)["foo"] |

querystring(string)["hello"]

Of course, we can also use the querystring module to parse the parameters in the POST request body, which will be demonstrated later.

Now let’s add some logic to the onRequest() function to find out the URL path requested by the browser:

var http = require("http");
var url = require("url");

function start() {
function onRequest(request, response) {
var pathname = url.parse(request.url).pathname;
console.log("Request for " pathname " received .");
response.writeHead(200, {"Content-Type": "text/plain"});
response.write("Hello World");
response.end();
}

http.createServer(onRequest).listen(8888);
console.log("Server has started.");
}

exports.start = start;
Okay, our application can now distinguish between different requests by the URL path of the request - this allows us to use routing (not yet completed) to route the request to the URL path. Baselines are mapped onto handlers.

In the application we are building, this means that requests from /start and /upload can be handled with different code. We'll see how this fits together later.

Now we can write the route. Create a file named router.js and add the following content:

function route(pathname) {
console.log("About to route a request for " pathname);
}

exports.route = route;
As you can see, this code does nothing, but for now it is as it should be. Before adding more logic, let's first look at how to integrate routing and servers.

Our servers should be aware of the existence of routes and use them effectively. We could of course hard-code this dependency to the server, but experience with programming in other languages ​​tells us that this would be a pain, so we will use dependency injection to loosely add the route. Modules (you can read Martin Fowlers' masterpiece on dependency injection for background knowledge).

First, let’s extend the server’s start() function to pass the routing function as a parameter:

At the same time, we will extend index.js accordingly so that the routing function can be injected into the server:

Here, the function we pass still does nothing.

If you start the application now (node ​​index.js, always remember this command line) and then request a URL, you will see the application output the corresponding information, which indicates that our HTTP server is already using the routing module, and The requested path will be passed to the route:

(The above output has removed the annoying parts related to the /favicon.ico request).

Behavior-Driven Execution

Please allow me to deviate from the topic again and talk about functional programming here.

Passing functions as arguments isn’t just for technical reasons. For software design, this is actually a philosophical question. Think about this scenario: In the index file, we can pass the router object in, and the server can then call the route function of this object.

Just like this, we pass something, and then the server uses this thing to complete something. Hi, that thing called routing, can you help me route this?

But the server doesn’t actually need such a thing. It just needs to get things done. In fact, in order to get things done, you don't need things at all, you need actions. That is, you don’t need a noun, you need a verb.

After understanding the most core and basic ideological transformation in this concept, I naturally understood functional programming.

I understood functional programming after reading Steve Yegge’s masterpiece Death Penalty in the Kingdom of Nouns. You should read this book too, really. This is one of the books about software that has ever given me the joy of reading.

Routed to the real request handler

Back to the topic, now our HTTP server and request routing module can communicate with each other as we expected, like a pair of close brothers.

Of course this is not enough. Routing, as the name suggests, means that we have to handle different URLs in different ways. For example, the "business logic" for processing /start should be different from that for processing /upload.

Under the current implementation, the routing process "ends" in the routing module, and the routing module is not the module that really "takes action" on the request, otherwise when our application becomes more complex, it will not be able to Scales well.

We temporarily refer to the function as the routing target as the request handler. Let's not rush into developing the routing module now, because there is little point in improving the routing module if the request handler is not ready.

Applications require new widgets, so add new modules -- there's no need to be novel about it anymore. Let’s create a module called requestHandlers, and for each request handler, add a placeholder function, and then export these functions as module methods:

In this way, we can connect the request handler and the routing module to make the routing "findable".

Here we have to make a decision: should we hardcode the requestHandlers module into the route for use, or add a little dependency injection? Although like other patterns, dependency injection should not be used just for usage, in this case, using dependency injection can make the coupling between the route and the request handler looser, and therefore make the route more reusable. .

This means we have to pass request handlers from the server to the route, but this feels even more outrageous. We have to pass a bunch of request handlers all the way from our main file to the server, and then pass them Passed from server to route.

So how do we pass these request handlers? Don't look at it now that we only have 2 handlers. In a real application, the number of request handlers will continue to increase. We certainly don't want to have to complete the request in the route every time there is a new URL or request handler. Mapping to handlers and tossing it over and over again. In addition, there are a lot of if request == x then call handler y in the routing, which also makes the system ugly.

Think about it carefully, there are a lot of things, each of which needs to be mapped to a string (that is, the requested URL)? It seems that an associative array works perfectly.

But the result is a bit disappointing, JavaScript does not provide associative arrays -- can you say that it does? In fact, in JavaScript, it is its objects that can really provide such functionality.

In this regard, http://msdn.microsoft.com/en-us/magazine/cc163419.aspx has a good introduction, I will excerpt it here:

In C or C#, when we talk about objects, we refer to instances of classes or structures. Objects have different properties and methods depending on the template they are instantiated from (the so-called class). But objects are not this concept in JavaScript. In JavaScript, an object is a collection of key/value pairs -- you can think of a JavaScript object as a dictionary with string keys.

But if a JavaScript object is just a collection of key/value pairs, how can it have methods? Well, the value here can be a string, a number, or... a function!

Okay, let’s finally get back to the code. Now that we have decided to pass a series of request handlers through an object, we need to inject this object into the route() function in a loosely coupled way.

We first introduce this object into the main file index.js:

Although handle is not just a "thing" (a collection of request handlers), I still recommend naming it with a verb, like this Doing this allows us to use more fluent expressions in routing, as explained later.

As you can see, mapping different URLs to the same request handler is easy: just add a property with the key "/" to the object, corresponding to requestHandlers.start, and we can clean Requests for concisely configured /start and / are handled by the start handler.

After completing the definition of the object, we pass it to the server as an additional parameter. For this purpose, server.js is modified as follows:

In this way, we add the handle parameter in the start() function, and pass the handle object as the first parameter to the route() callback function.

Then we modify the route() function in the route.js file accordingly:

Through the above code, we first check whether the request handler corresponding to the given path exists, and if it exists, call the corresponding function directly. We can get the request processing function from the passed object in the same way as getting elements from the associative array, so we have a concise and smooth expression in the form of handle[pathname]();, which feels like mentioning in the front to: "Hey, please help me with this path".

With this, we have the server, route and request handler together. Now we start the application and visit http://localhost:8888/start in the browser. The following log can show that the system calls the correct request handler:

And open http://localhost:8888/ in the browser, you can see that this request is also processed by the start request handler:

Let the request handler respond

Very good. But now it would be nice if the request handler could return some meaningful information to the browser instead of just "Hello World".

What should be remembered here is that the "Hello World" information obtained and displayed after the browser makes a request still comes from the onRequest function in our server.js file.

In fact, "processing a request" simply means "responding to a request." Therefore, we need to enable the request handler to "talk" to the browser like the onRequest function.

Bad implementation

For developers like us with PHP or Ruby technical background, the most straightforward implementation method is actually not very reliable: it seems effective, but in fact it may not be so.

What I mean here by "straightforward implementation" is to let the request handler directly return (return()) the information they want to display to the user through the onRequest function.

Let’s implement it like this first, and then look at why this is not a good way to implement it.

Let’s start by having the request handler return the information that needs to be displayed in the browser. We need to modify requestHandler.js to the following form:

Okay. Likewise, request routing needs to return to the server the information that the request handler returns to it. Therefore, we need to modify router.js to the following form:

As shown in the above code, when the request cannot be routed, we also return some related error information.

Finally, we need to refactor our server.js so that it responds to the browser with the content returned by the request handler via the request route, like this:

If we run the refactored application, everything will work fine: request http://localhost:8888/start, and the browser will output "Hello Start" , requesting http://localhost:8888/upload will output "Hello Upload", while requesting http://localhost:8888/foo will output "404 Not found".

Okay, so what’s the problem? To put it simply: when a request handler needs to perform non-blocking operations in the future, our application will "hang".

Don’t understand? It doesn’t matter, let’s explain it in detail below.

Blocking and non-blocking

As mentioned before, problems arise when including non-blocking operations in request handlers. However, before talking about this, let's first take a look at what blocking operations are.

I don’t want to explain the specific meaning of “blocking” and “non-blocking”, let’s just look at what happens when blocking operations are added to the request handler.

Here, let’s modify the start request handler. We let it wait for 10 seconds before returning “Hello Start”. Because there is no operation like sleep() in JavaScript, we can only use a little Hack to simulate the implementation.

Let us modify requestHandlers.js to the following form:

In the above code, when the function start() is called, Node.js will wait for 10 seconds before returning "Hello Start". When upload() is called, it will return immediately as before.

(Of course, this is just a simulation of sleeping for 10 seconds. In actual scenarios, there are many such blocking operations, such as some long-term calculation operations.)

Let’s take a look at what changes our changes have brought.

As usual, we need to restart the server first. In order to see the effect, we need to perform some relatively complicated operations (follow me): First, open two browser windows or tabs. Enter http://localhost:8888/start in the address bar of the first browser window, but don't open it yet!

Enter http://localhost:8888/upload in the address bar of the second browser window. Again, don’t open it yet!

Next, do the following: press Enter in the first window ("/start"), then quickly switch to the second window ("/upload") and press Enter.

Notice what happened: the /start URL took 10 seconds to load, which is what we expected. However, the /upload URL actually took 10 seconds, and it did not have an operation similar to sleep() in the corresponding request handler!

Why is this? The reason is that start() contains blocking operations. To put it figuratively, "it blocks all other processing work."

This is obviously a problem, because Node has always advertised itself like this: "In node, except for the code, everything is executed in parallel."

What this sentence means is that Node.js can still process tasks in parallel without adding additional threads - Node.js is single-threaded. It implements parallel operations through event loop, and we should make full use of this - avoid blocking operations as much as possible, and instead use non-blocking operations.

However, to use non-blocking operations, we need to use callbacks by passing the function as a parameter to other functions that take time to process (for example, sleeping for 10 seconds, or querying the database, or performing a large number of calculations ).

For Node.js, it is handled like this: "Hey, probablyExpensiveFunction() (Translator's Note: This refers to functions that take time to process), you continue to deal with your things, I (Node. js thread) I won’t wait for you for now. I will continue to process the code behind you. Please provide a callbackFunction(). I will call the callback function after you finish processing. Thank you! ”

(If you want to know more details about event polling, you can read Mixu’s blog post - Understanding node.js event polling.)

Next, we will introduce a wrong way to use non-blocking operations.

Like last time, we modified our application to expose the problem.

This time we still use the start request handler to "operate". Modify it to the following form:

In the above code, we introduced a new Node.js module, child_process. The reason why it is used is to implement a simple and practical non-blocking operation: exec().

What does exec() do? It executes a shell command from Node.js. In the above example, we use it to get all the files in the current directory ("ls -lah"), and then output the file information to the browser when /startURL is requested.

The above code is very intuitive: Create a new variable content (initial value is "empty"), execute the "ls -lah" command, assign the result to content, and finally return content.

As usual, we start the server and access "http://localhost:8888/start".

A beautiful web page will be loaded with the content "empty". What's going on?

At this time, you may have roughly guessed that exec() plays a magical role in non-blocking. It's actually a good thing, with it, we can perform very time-consuming shell operations without forcing our application to stop and wait for the operation.

(If you want to prove this, you can replace "ls -lah" with a more time-consuming operation such as "find /" to achieve the effect).

However, judging from the results displayed by the browser, we are not satisfied with our non-blocking operation, right?

Okay, next, let’s fix this problem. While we're at it, let's take a look at why the current approach doesn't work.

The problem is that in order to perform non-blocking work, exec() uses a callback function.

In our case, the callback function is the anonymous function passed as the second parameter to exec():

Now we come to the root of the problem: we The code is executed synchronously, which means that after calling exec(), Node.js will execute return content immediately; at this time, content is still "empty" because the callback function passed to exec() has not yet been executed. To - because the operation of exec() is asynchronous.

The operation of "ls -lah" here is actually very fast (unless there are millions of files in the current directory). This is why the callback function will be executed quickly - but it is still asynchronous anyway.

To make the effect more obvious, let's imagine a more time-consuming command: "find /", which takes about 1 minute to execute on my machine. However, although in the request handler, I put "ls - lah" is replaced with "find /", when opening the /start URL, you can still get the HTTP response immediately - obviously, when exec() is executed in the background, Node.js itself will continue to execute the following code. And we assume here that the callback function passed to exec() will only be called after the "find /" command is executed.

So how can we display the file list in the current directory to the user?

Okay, now that we understand this bad implementation, let’s introduce how to make the request handler respond to browser requests in the correct way.

Response to requests with non-blocking operations

I just mentioned the phrase – “the right way”. In fact, the "right way" is usually not simple.

However, there is such an implementation solution using Node.js: function passing. Let's take a look at how to implement this in detail.

So far, our application has been able to pass the content returned by the request handler (the request handler will eventually display content to the user) is passed to the HTTP server.

Now we adopt the following new implementation method: instead of passing the content to the server, this time we use the method of "passing" the server to the content. From a practical perspective, the response object (obtained from the server's callback function onRequest()) is passed to the request handler through the request routing. The handler can then respond to the request using functions on that object.

That’s the principle, let’s implement this solution step by step.

Start with server.js:

Compared with the previous method of obtaining the return value from the route() function, this time we pass the response object as the third parameter to the route() function, and we will All response-related function calls in the onRequest() handler are removed, because we want this part of the work to be done by the route() function.

Let’s take a look at our router.js:

Same pattern: instead of getting the return value from the request handler, this time the response object is passed directly.

If there is no corresponding request handler, we will directly return a "404" error.

Finally, we modify requestHandler.js to the following form:

Our handler function needs to receive the response parameter in order to respond directly to the request.

The start handler does the request response operation in the anonymous callback function of exec(), while the upload handler still simply replies "Hello World", but this time it uses the response object.

Now we start the application (node ​​index.js) again and everything will work fine.

If you want to prove that the time-consuming operations in the /start handler will not block the immediate response to the /upload request, you can modify requestHandlers.js to the following form:

이렇게 하면 http://localhost:8888/start를 요청하면 로딩하는데 10초가 걸리고, http://localhost:8888/upload를 요청하면 바로 응답하게 된다. , 현재 /start 응답이 아직 처리 중이더라도 마찬가지입니다.

더 유용한 시나리오

지금까지 우리는 잘 해왔지만 우리의 애플리케이션은 실용성이 없습니다.

서버, 요청 라우팅 및 요청 핸들러가 완료되었습니다. 이전 사용 사례에 따라 웹사이트에 상호 작용을 추가해 보겠습니다. 사용자가 파일을 선택하고 파일을 업로드한 다음 업로드된 파일을 브라우저에서 확인합니다. 간단하게 유지하기 위해 사용자가 이미지만 업로드하고 앱이 해당 이미지를 브라우저에 표시한다고 가정합니다.

자, 이제 차근차근 구현해 보겠습니다. 이전에 이미 많은 JavaScript 원리와 기술 내용을 소개했으므로 이번에는 속도를 조금 높여보겠습니다.

이 기능을 구현하려면 다음과 같은 두 단계가 있습니다. 먼저 POST 요청(파일이 아닌 업로드)을 처리하는 방법을 살펴보겠습니다. 그런 다음 파일 업로드를 위해 Node.js의 외부 모듈을 사용합니다. 이 구현에는 두 가지 이유가 있습니다.

첫째, Node.js에서 기본 POST 요청을 처리하는 것은 비교적 간단하지만 그 과정에서 많은 것을 배울 수 있습니다.
둘째, Node.js를 사용하여 파일 업로드(멀티파트 POST 요청)를 처리하는 것은 상대적으로 복잡하며 이 책의 범위를 벗어납니다. 그러나 외부 모듈을 사용하는 방법은 이 책의 범위에 속합니다.

POST 요청 처리

간단한 예를 생각해 보겠습니다. 사용자가 콘텐츠를 입력할 수 있는 텍스트 영역을 표시한 다음 POST 요청을 통해 서버에 제출합니다. 마지막으로 서버는 요청을 수신하고 핸들러를 통해 입력 내용을 브라우저에 표시합니다.

/start 요청 핸들러는 텍스트 영역이 있는 양식을 생성하는 데 사용되므로 requestHandlers.js를 다음 형식으로 수정합니다.

function start(response) {
console.log("요청 핸들러 'start'가 호출되었습니다.");

var body = ''
''
''
'

'
''
'

' 🎜> ''
' '
'

'
''
'';

response.writeHead(200, {"Content-Type": "text/html"});

response.write(body);
response.end();
}

function upload(response) {

console.log("요청 핸들러 'upload'가 호출되었습니다.");
response.writeHead(200, {"Content-Type": "text/plain"} );
response.write("안녕하세요 업로드");
response.end();
}

exports.start = start;

exports.upload = upload;
자, 이제 우리의 신청서가 매우 완성되어 Webby Awards를 수상할 수도 있습니다. 하하. (번역자 주: 웨비 어워드는 국제디지털예술과학아카데미(International Academy of Digital Arts and Sciences)가 후원하는 세계 최고의 웹사이트를 선정하는 상입니다. 자세한 내용은 상세 설명을 참조하세요.) http://localhost를 방문하시면 보실 수 있습니다: 8888/start in your browser 간단한 양식입니다. 서버를 다시 시작하는 것을 잊지 마세요!

다음과 같이 말할 수도 있습니다. 시각적 요소를 요청 핸들러에 직접 배치하는 방식은 너무 추악합니다. 그것은 사실이지만 이 책에서는 MVC와 같은 패턴을 소개하고 싶지 않습니다. 왜냐하면 그것은 JavaScript나 Node.js 환경에 대한 이해와 관련이 없기 때문입니다.

나머지 공간에서는 더 흥미로운 문제에 대해 논의하겠습니다. 사용자가 양식을 제출하면 /upload 요청 핸들러가 트리거되어 POST 요청을 처리합니다.

이제 우리는 초보자 중 전문가이므로 비동기 콜백을 사용하여 POST 요청 데이터를 비차단 방식으로 처리하는 것을 생각하는 것이 당연합니다.

여기에서는 비차단이 사용됩니다.