Start-Up Note-node.js event-driven callbacks

Event-driven callbacks

This is a difficult question to answer (at least for me), but this is how node. js Native works. It's event-driven, which is why it's so fast.

You might want to spend some time reading Felix Geisendörfer's masterpiece Understanding node. js, which introduces some background knowledge.

This is all due to the fact that node. JS is event-driven. Well, I don't really know the meaning of the sentence in particular. But I'll try to explain why it makes sense for us to write Web applications with node. JS (based application).

When we use the http.createserver method, of course we don't just want a server that listens on a port, we also want it to do something when the server receives an HTTP request.

The problem is that this is asynchronous: The request can arrive at any time, but our server is running in a single process.

When writing PHP applications, we are not worried at all: whenever a request comes in, the Web server (usually Apache) creates a new process for the request and starts executing the appropriate PHP script from start to finish.

So in our node. JS program, when a new request arrives at Port 8888, how do we control the process?

Well, that's where Node.js/javascript's event-driven design can really help-although we have to learn some new concepts to master it. Let's take a look at how these concepts are applied in our server code.

We created the server and passed a function to the method that created it. Whenever our server receives a request, the function is called.

We don't know when this is going to happen, but we now have a place to deal with the request: It's the function we passed in the past. It does not matter whether it is a pre-defined function or an anonymous function.

This is the legendary callback . We pass a function to a method that calls this function to make a callback when a corresponding event occurs.

At least for me, it takes some effort to understand it. If you're still unsure, read Felix's blog post again.

Let's try to figure out the new concept. How do we prove that our code continues to work after the server is created, even if there is no HTTP request coming in and our callback function is not invoked? Let's try this:

Varhttp=Require("http");

functionONrequest(Request,Response){
Console.Log("Request received.");
Response.Writehead(200,{ "Content-type" : "Text/plain" });    Response. Write "Hello World"    Response. End } 
 
 Http. Createserveronrequest8888 
 Console. Log ( "Server has started."                

Note: In the place where onrequest (our callback function) was triggered, I output a text with Console.log . after the HTTP server has started working, a text is also output.

When we run its node server.js as usual, it will output "server has started." On the command line immediately. When we make a request to the server (in the browser to access http://localhost:8888/), "request received." This message will appear on the command line.

This is the event-driven asynchronous server-side JavaScript and its callbacks!

(Note that when we access the Web page on the server, our server may output two times "Request received.") That's because most servers will try to read Http://localhost:8888/favicon.ico when you visit http://localhost:8888/

How the server handles the request

OK, so let's take a quick look at the rest of our server code, the main part of our callback function onrequest () .

When the callback starts and our onrequest () function is triggered, two parameters are passed in: request and response .

They are objects, and you can use their methods to handle the details of HTTP requests and respond to requests (such as sending something back to the requesting browser).

So our code is: When the request is received, use the response.writehead () function to send a content type of HTTP status 200 and HTTP header (Content-type), using Response.Write ( ) function to send the text "Hello World" in the appropriate body of HTTP.

Finally, we call Response.End () to complete the response.

For now, we don't care about the details of the request, so we 're not using the requests object.

Where are the modules on the server?

OK, as I promised, we can now go back to the question of how we organize the application. We now have a very basic HTTP server code in the server.js file, and I mentioned that usually we have a file called Index.js to call the application's other modules (such as server.js Server module) to boot and launch the app.

Let's talk about how to turn server.js into a real node. js module so that it can be used by our index.js Master file (which is not working).

Perhaps you have noticed that we have already used the module in the code. Like this:

var= require("http");

...

HTTP.  Createserver(...);  

node. js comes with a module called "http", which we request in our code and assign the return value to a local variable.

This turns our local variables into an object that has the public methods provided by all HTTP modules.

It is customary to give this local variable the same name as the module name, but you can also follow your own preferences:

var= require("http");

...

Foo.  Createserver(...);  

Well, it's clear how to use the node. JS internal module. How do we create our own modules and how do we use them?

When we turn server.js into a real module, you can figure it out.

In fact, we don't have to make too many changes. Turning a piece of code into a module means that we need to export the part that we want to provide its functionality to the script that requested the module.

For now, our HTTP server needs to be exported with a very simple function, because the script for the request server module simply needs to start the server.

We put our server script in a function called start , and then we export the function.

Varhttp=Require("http");

functionStart(){
functionONrequest(Request,Response){
Console.Log("Request received.");
Response.Writehead(200,{"Content-type":"Text/plain"});
Response.Write( "Hello World" );  
     Response.   } 
 
   Http. Createserveronrequest8888   Console. Log ( "Server has started."  
 } 
 
 Exports.= Start        

In this way, we can now create our main file index.js and launch our HTTP in it, although the server's code is still in server.js .

Create the index.js file and write the following:

var= require("./server");

Server.  Start();  

As you can see, we could use the server module just like any other built-in module: request this file and point it to a variable, where the exported function can be used by us.

All right. We can now launch our app from our main script, and it's still the same way:

Node Index.js

Very well, we can now put different parts of our application into different files, and connect them together by building a module.

We still only have the initial part of the entire application: we can receive HTTP requests. But we have to do something-the server should react differently to different URL requests.

For a very simple application, you can do this directly in the callback function onrequest () . But as I said, we should add some abstract elements to make our example a little bit more interesting.

Handling different HTTP requests is a different part of our code, called "Routing"--then we'll create a module called routing next.

How to make a request for "routing"

We want to provide the requested URL and other required get and post parameters for the route, and then the route needs to execute the corresponding code based on that data (the "code" here corresponds to the third part of the entire application: a series of handlers that actually work when the request is received).

Therefore, we need to look at the HTTP request and extract the requested URL and the Get/post parameter from it. Whether this feature should belong to a routing or server (or even as a function of a module itself) is really worth exploring, but here it is tentatively the function of our HTTP server.

All the data we need will be included in the request object, which is passed as the first parameter of the onrequest () callback function. But in order to parse this data, we need additional node. JS modules, which are URLs and QueryString modules, respectively.

                               Url.parse (String). Query                                           |           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, there will be a demo later.

Now let's add some logic to the onrequest () function to find the URL path to the browser request:

Varhttp=Require("http");
VarUrl=Require("url");

functionStart(){
functionONrequest(Request,Response){
VarPathname=Url.Parse(Request.Url).Pathname;
Console.Log("Request for"+Pathname+"Received.");
Response.Writehead(200,{"Content-type":"Text/plain"});
Response.Write( "Hello World" );  
     Response.   } 
 
   Http. Createserveronrequest8888   Console. Log ( "Server has started."  
 } 
 
 Exports.= Start        

Well, our app can now differentiate between requests by the URL path of the request-which allows us to use the route (not yet completed) to map the request to the handler using the URL path as a baseline.

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

Now we can write the route, create a file named router.js , add the following:

function Route(pathname){
Console.  Log("about-route a request for"+ pathname);
}

Exports.  = route;   

As you can see, this code doesn't do anything, but for now it's supposed to be. Before adding more logic, let's take a look at how to integrate the routing and the server together.

Our servers should be aware of the existence of routes and use them effectively. We can certainly bind this dependency to the server in a hard-coded way, but the programming experience of other languages tells us that this can be very painful, so we will add the routing module loosely using dependency injection (you can read Martin Fowlers a masterpiece of dependency injection as a background knowledge).

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

Varhttp=Require("http");
VarUrl=Require("url");

functionStart(Route){
functionONrequest(Request,Response){
VarPathname=Url.Parse(Request.Url).Pathname;
Console.Log("Request for"+Pathname+"Received.");

Route(Pathname);

Response.Writehead(200,{"Content-type":"Text/plain"});
Response.Write( "Hello World" );  
     Response.   } 
 
   Http. Createserveronrequest8888   Console. Log ( "Server has started."  
 } 
 
 Exports.= Start        

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

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

Server.  Start(router.  Route);

Here, the functions we pass are still not doing anything.

If you start the app now (node index.js, always remember this command line ), then request a URL, you will see the application output the appropriate information, indicating that our HTTP server is already using the routing module, and will pass the requested path to the route:

bash$ node Index.jsrequest For/foo received. About to route a request For/foo

(The above output has been removed from the more annoying/favicon.ico request related sections).

Start-Up Note-node.js event-driven callbacks