nodejs_recipes
Node.js Recipes are structured in a Cookbook format featuring recipes that contain problem statements and solutions. A detailed explanation follows each problem statement of the recipe. This is usually contained within the solution; however, an optional discussion section can often contain other useful information helping to demonstrate how the solution works.
Source: http://www.nodejsrecipes.com
The old versions of JavaScript had no import, include, or require, so many different approaches to this problem have been developed.
But recent versions of JavaScript have standards like ES6 modules to import modules, although this is not supported yet by most browsers. Many people using modules with browser applications use build and/or transpilation tools to make it practical to use new syntax with features like modules.
ES6 Imports
Note that currently (unless you are using the latest MS Edge) this will require the use of build and/or transpilation tools.
// module.js
export function hello() {
return "Hello";
}
// main.js
import {hello} from 'module'; // or './module'
let val = hello(); // val is "Hello";
Node.js require
Node.js is currently using a module.exports/require system. You can use babel to transpile if you want the import syntax.
// mymodule.js
exports.hello = function() {
return "Hello";
}
// server.js
const myModule = require('./mymodule');
let val = myModule.hello(); // val is "Hello"
There are other ways for JavaScript to include external JavaScript contents in browsers that do not require preprocessing.
Ajax Loading
Load an additional script with an Ajax call and then use eval. This is the most straightforward way, but it is limited to your domain because of the JavaScript sandbox security model. Using eval also opens the door to bugs and hacks.
jQuery Loading
The jQuery library provides loading functionality in one line:
$.getScript("my_lovely_script.js", function(){
alert("Script loaded but not necessarily executed.");
});
Dynamic Script Loading
Add a script tag with the script URL in the HTML. To avoid the overhead of jQuery, this is an ideal solution.
The script can even reside on a different server. Furthermore, the browser evaluates the code. The <script> tag can be injected into either the web page <head>, or inserted just before the closing </body> tag.
Both of these solutions are discussed and illustrated in JavaScript Madness: Dynamic Script Loading.
Detecting when the script has been executed
Now, there is a big issue you must know about. Doing that implies that you remotely load the code. Modern web browsers will load the file and keep executing your current script because they load everything asynchronously to improve performance. (This applies to both the jQuery method and the manual dynamic script loading method.)
It means that if you use these tricks directly, you won't be able to use your newly loaded code the next line after you asked it to be loaded, because it will be still loading.
For example: my_lovely_script.js contains MySuperObject:
var js = document.createElement("script");
js.type = "text/javascript";
js.src = jsFilePath;
document.body.appendChild(js);
var s = new MySuperObject();
Error : MySuperObject is undefined
Then you reload the page hitting F5. And it works! Confusing...
So what to do about it ?
Well, you can use the hack the author suggests in the link I gave you. In summary, for people in a hurry, he uses an event to run a callback function when the script is loaded. So you can put all the code using the remote library in the callback function. For example:
function loadScript(url, callback)
{
// Adding the script tag to the head as suggested before
var head = document.getElementsByTagName('head')[0];
var script = document.createElement('script');
script.type = 'text/javascript';
script.src = url;
// Then bind the event to the callback function.
// There are several events for cross browser compatibility.
script.onreadystatechange = callback;
script.onload = callback;
// Fire the loading
head.appendChild(script);
}
Then you write the code you want to use AFTER the script is loaded in a lambda function:
var myPrettyCode = function() {
// Here, do what ever you want
};
Then you run all that:
loadScript("my_lovely_script.js", myPrettyCode);
Note that the script may execute after the DOM has loaded, or before, depending on the browser and whether you included the line script.async = false;. There's a great article on Javascript loading in general which discusses this.
Source Code Merge/Preprocessing
As mentioned at the top of this answer, many developers now use build/transpilation tool(s) like WebPack, Babel, or Gulp in their projects, allowing them to use new syntax and support modules better, combine files, minify, etc.
There is a way to write to an external command: process.createChildProcess (documentation) returns an object with a write method. createChildProcess isn't as convenient though, because it doesn't buffer stdout and stderr, so you will need event handlers to read the output in chunks.
var stdout = "", stderr = "";
var child = process.createChildProcess("someCommand");
child.addListener("output", function (data) {
if (data !== null) {
stdout += data;
}
});
child.addListener("error", function (data) {
if (data !== null) {
stderr += data;
}
});
child.addListener("exit", function (code) {
if (code === 0) {
sys.puts(stdout);
}
else {
// error
}
});
child.write("This goes to someCommand's stdin.");
None of the code you show is using recursion. When you call useFile it calls posix.stat(), which returns, and useFile terminates as it has run to completion. At some later time, when the call to posix.stat() has completed within the underlying system and the results are available, the callback function you added for that will be executed. That calls posix.open(), and then terminates as it has run to completion. Once the file has been successfully opened, the callback function for that will execute, calling posix.read(), and will then terminate as it, too, has run to completion. Finally, when the results of the read are available, the innermost function will be executed.
The important point is that each function runs to completion, as the calls to the posix.*() functions are non-blocking: that is, they return immediately, having caused some magic to be started off in the underlying system. So each of your functions terminates, and later an event will cause the next function to execute; but at no point is there any recursion.
The nested structure of the code can give one the impression that the stuff inside will have to finish before the stuff outside can get to its own end point. But in this style of asynchronous event-driven programming it makes more sense to see the nesting in terms of deeper => happens-later-than.
EDIT: Try adding some logging statements immediately before the end of each nested function; this will help to illustrate that the order in which they complete is from the outside inwards.
I'm not aware of any printed resources about node.js. Some good places to start are:
The official node.js documentation
The web site howtonode.org with a lot of tutorials
The video of Ryan Dahl's (node.js creator) talk at the JSConf.eu
A nice blog post about node.js by Simon Willison
The mailing list archive
The source code of node.js projects on github
This is perfectly normal behaviour. Your callbacks are executed at some later point (asynchronously) but still reference the scope your for loop was running in. All callback references to file will therefore have the last value it was set to.
What you want to do is create a new function scope, assign the current value of file to a local variable and create the callback inside that scope.
for (var i=0;i<files.length;i++){
var file = dir+'/'+files[i];
(function() {
var file_on_callback = file;
sys.puts('file assigned: '+ file_on_callback);
posix.stat(file_on_callback).addCallback(function(stats){
sys.puts('stats returned: '+ file_on_callback);
if (stats.isDirectory())
posix.readdir(file_on_callback).addCallback(function(files){
parse_file_list(file_on_callback, files);
});
else if (stats.isFile())
process.watchFile(file_on_callback, restart_server);
});
})(); // This creates and executes a new function with its own scope.
}
I think the advantages are:
Web development in a dynamic language (JavaScript) on a VM that is incredibly fast (V8). It is much faster than Ruby, Python, or Perl.
Ability to handle thousands of concurrent connections with minimal overhead on a single process.
JavaScript is perfect for event loops with first class function objects and closures. People already know how to use it this way having used it in the browser to respond to user initiated events.
A lot of people already know JavaScript, even people who do not claim to be programmers. It is arguably the most popular programming language.
Using JavaScript on a web server as well as the browser reduces the impedance mismatch between the two programming environments which can communicate data structures via JSON that work the same on both sides of the equation. Duplicate form validation code can be shared between server and client, etc.
The V8 debugger released as part of the Google Chrome Developer Tools can be used to debug Node.js scripts. A detailed explanation of how this works can be found in the Node.js GitHub wiki.
There is also ndb, a command line debugger written in Node.js itself.
A good, up to date alternative to supervisor is nodemon:
Monitor for any changes in your node.js application and automatically restart the server - perfect for development
To use nodemon:
$ npm install nodemon -g
$ nodemon app.js
I think each solution has its own advantages/disadvantages
here a list of SSJS solutions:
Aptana Jaxer:
sadly abandoned
Sitepoint Persevere:
based on rhino -
include JSDB, supports JSON Query -
by Kris Zyp, the author of JSON Schema
RingoJS:
based on rhino -
ex Helma NG successor of Helma which existed from long time ago -
multi-thread -
nice community -
great actor on CommonJS
Narwhal:
can work on either spidermonkey, V8, or webkit JavaScriptCore -
another great actor on CommonJS -
defined the JSGI API in the Jack Server
Joyent NodeJS:
based on V8
(fast) -
all is running in a single thread -
all the code must be written using callbacks -
lot of modules available via npm (Node Package Manager)
4D Wakanda:
based on Webkit JavaScriptCore aka SFX or Nitro (which has been faster than V8 and could be faster again) -
include an NoSQL Object oriented JavaScript datastore with a native REST API -
multi-threaded -
provides a studio with a debugger, a Model Designer, and a GUI Designer -
provides a Framework with Widgets directly bindable to the datastore and between each others
APE project: based on spidermonkey - a Push engine to synchronize in live data between many visitor browsers
10gen MongoDB: A NoSQL Document store allowing code in either Erlang & JavaScript (using spidermonkey)
Apache CouchDB: Another NoSQL Document store also allowing code in either Erlang & JavaScript (using spidermonkey)
See a Server-Side JavaScript presentation with some history, benchmarks, & descriptions
According to this, the problem with approach #2 that respond was called before a status code was set.
This works:
get('/2', function () {
var myRequest = this;
function up(s) {
myRequest.halt(200, s.toUpperCase());
}
return posix.cat('/etc/motd').addCallback(up);
});
http://boldr.net/mvc-stack-node-js-ejsgi-scylla-mustache is a great little article with a full github example of a MVC pattern using dirfferent Node modules. It also lists alternate modules currently available. It answered this question for me better than http://howtonode.org/ which has some good tuts but I couldn't find anything on MVC there.
A possible immediate source of your problem is the URL encoding. I see the plus operator is transmitted as-is. That's dangerous, because + used to mean space in the traditional encoding. http://www.faqs.org/rfcs/rfc1738
node-http-proxy sounds like what you want
var sys = require('sys'),
http = require('http'),
httpProxy = require('http-proxy').httpProxy;
http.createServer(function (req, res){
var proxy = new httpProxy;
proxy.init(req, res);
proxy.proxyRequest('localhost', '9000', req, res);
}).listen(8000);
http.createServer(function (req, res){
res.writeHead(200, {'Content-Type': 'text/plain'});
res.write('request successfully proxied!' + '\n' + JSON.stringify(req.headers, true, 2));
res.end();
}).listen(9000);</code></pre>
The server that node.js allows you to build, is an application server, which means that state is preserved, between request, on the server side. The following snippet demonstrates this:
var sys = require('sys'),
http = require('http');
var number = 0;
http.createServer(function (req, res) {
console.log(req.method, req.url);
res.writeHead(200, {'Content-Type': 'text/html'});
res.write('<h1>Number is: ' + number + '</h1>');
res.end();
number++;
}).listen(8000);
sys.puts('Server running at http://127.0.0.1:8000/');
Have you updated the Content-Length to match the gzipped size? It seems like that might screw up the decoding.
There are a lot of details in the filesystem API. The most common way (as far as I know) is:
var fs = require('fs');
fs.writeFile("/tmp/test", "Hey there!", function(err) {
if(err) {
return console.log(err);
}
console.log("The file was saved!");
});
I would highly recommend Redis. It is a key/value store with set and list operations. It also supports atomic operations for counters. There is a client for Redis for Node.js available on github. Here is how I would implement your features:
Storing the votes
INCR votes:option:<option>
Summarizing the votes
MGET votes:option:<option1> votes:option:<option2> ... votes:option:<optionN>
Preventing multiple votes (create an expiring lock key for client IP)
EXPIRE lock:<encoded ip> 60
It's hidden in the source together with C++ sources and headers at <node-installation>/src/node.js.
You can't modify node.js and expect changes to have a direct effect. After a change you have to rebuild with make. You also can't do many things, for example you have to use process.stdout.write() instead of sys.print().
Good luck!
It is possible. Just use response.write() multiple times.
var body = ["hello world", "early morning", "richard stallman", "chunky bacon"];
// send headers
response.writeHead(200, {
"Content-Type": "text/plain"
});
// send data in chunks
for (piece in body) {
response.write(body[piece], "ascii");
}
// close connection
response.end();
You may have to close and reopen connection every 30 seconds or so.
EDIT: this is the code I actually tested:
var sys = require('sys'),
http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/html'});
var currentTime = new Date();
sys.puts('Starting sending time');
setInterval(function(){
res.write(
currentTime.getHours()
+ ':' +
currentTime.getMinutes()
+ ':' +
currentTime.getSeconds() + "\n"
);
setTimeout(function() {
res.end();
}, 10000);
},1000);
}).listen(8090, '192.168.175.128');
I connected to it by Telnet and its indeed gives out chunked response. But to use it in AJAX browser has to support XHR.readyState = 3 (partial response). Not all browsers support this, as far as I know. So you better use long polling (or Websockets for Chrome/Firefox).
EDIT2: Also, if you use nginx as reverse proxy to Node, it sometimes wants to gather all chunks and send it to user at once. You need to tweak it.
Looking at your link it seems to me that all pub/sub work is done by Nginx, Ruby code is used only to test it and send messages. Clients are still using long polling:
In the script above, every five seconds a publisher emits a new event to our Nginx server, which in turn, pushes the data to two subscribers which have long-polling connections open and are waiting for data. Once the message is sent to each subscriber, Nginx closes their connections and the clients then immediately re-establish them to wait for the next available message.
Nginx serves as simple retranslator for messages (very clever setup BTW, thanks for the link).
To put it short: browsers aren't capable for this sort of connection you trying to do. This is what WebSockets were invented for.
Later i'll make some code in Node.js to use this setup with Nginx (I'm interested in it too).
Two distinct processes won't be able to use the same IP port on a same IP address. Thus, two processes won't be able to use the same incoming stream of data coming out of the TCP connection. If they use different ports, there's no problem.
If the two processes use the same IP port, as HTTP is a protocol that sits on top of TCP, it means that your TCP process can be used as a pipe by the HTTP process. The TCP process will connect to the IP port, do its stuff, and forward the data to the HTTP process that will handle it.
By default, node.js has a 60 second timeout for TCP/IP connections. You can get around this by explicitly setting the timeout. Here's a quick example:
http.createServer(function (req, res) {
// Connection now times out after 120 seconds
req.connection.setTimeout(120000);
// ... TODO: server logic ...
}).listen(8000);
You can tell node to hold the connection open indefinitely by setting to the timeout to 0. Also, note that the default 60 second timeout applies to all socket connections in addition to TCP/IP.
Just get cookies from Set-Cookie param in response headers and send them back with future requests. Should not be hard.
By default the http.Server class of Node.js accepts any http method.
You can get the method using request.method (api link).
Example:
var sys = require('sys'),
http = require('http');
http.createServer(function (request, response) {
response.writeHead(200, {'Content-Type': 'text/plain'});
response.write(request.method);
response.end();
}).listen(8000);
sys.puts('Server running at http://127.0.0.1:8000/');
This will create a simple http server on the port 8000 that will echo the method used in the request.
If you want to get a POST you should just check the request.method for the string "POST".
Update regarding response.end:
Since version 0.1.90, the function to close the response is response.end instead of response.close. Besides the name change, end can also send data and close the response after this data is sent unlike close. (api example)
