- Joined
- Jun 8, 2007
- Messages
- 1,985
- Reaction score
- 490
Hi all, this thread is reserved for those who know of or want to know of excellent resources for learning and performing with Node.JS. All things Socket.IO, Express.JS, MongoDB, and Node.JS are welcome! Let's try to keep things like spidermonkey out because, seriously, Node.JS is clutterred enough, let's work on getting some utilities and coding guidelines together so that more people can start using Node.JS today!
Make sure everyone gets a copy of Node.JS, and NPM (node package manager) so that it's trivial to install packages such as express, socket.io, mongodb, and more!
I'm making some pretty cool stuff with node.js, and I'll be sure to post some code examples/tutorial later on.
I'm hoping the community here at RZ may help me to gather up a good bundle of information for Node.JS.
Okay. Anyone who's gone so far as to download Node.JS has probably tried this famous HTTP server example from nodejs.org:
If you're going to make a web app to print some text to a browser on every request, then this example is for you. Okay let's get back to real life now. The above example compares wonderfully to other hello world servers, but I can't think of any production-level server where the goal is that simple. The truth is, once you try to get a little deeper into Node.JS following the above semantics, you run into spaghetti code very fast. The reason for that is "Callback Madness."
Okay, so let's do a similar thing with express:
The above code will not respond 'hello world' on every request, I only told express to respond that for '/'. Nothing else is defined. So if you visit
If you don't have express installed, but you do have npm, you can (in your command prompt/terminal) type: "npm install express" to install express.js!
So, there's no immediate proof that express solves the callback problem, so let's dig a little deeper. At the moment you may be thinking: What exactly does S-p-n mean by "Callback Madness"? That node.JS example looks easy- perhaps just as simple as express.
So let's try to make the Node.JS HTTP module example server listen on '/'- just like express module is doing.
Okay, not so bad, but there's already a noticeable complexity problem arising under our nose. What happens if we want to add more requests? What happens if we want to host a file server like many other HTTP servers do? Well, there's modules to help us with that, but there's even better modules that do most of the heavy lifting for us.
Don't get me wrong, I tried to make a sustainable Node.JS file system module, and a sustainable Socket.IO module already- I don't give up that easily. And it's really not that I gave up, it's that there are people spending just as much time on express as I am on my custom stuff (well, probably more). Using the HTTP library you would need to include the 'fs' library or similar, and you'll have to do some crazy heavy-lifting like I did to make a good file-server with gZip compression and so on. Actually, it's probably a good 50 lines of JavaScript- possibly more if you want to add any cool dynamic magic to the mix. That's not too bad, so it's possible to scale Node.JS into a maintainable production-level server. But there's already an easier way.
Here's how to host a file-system in express:
Notice there's no callback madness- the deepest level is still 1 tab
So now it's possible to load the server file, I named mine 'test.js' so when I visit
When you build your own file server, you need to worry about all of these security concerns. When you're using express, you need to think about these concerns, but with a little less uncertainty.
We are certain our server-side code is available, and we can make just as certain the files are safe by placing the file-system we want to serve in a public directory. It's no surprise files from ./public are going to be public, so it's a little easier for web developers to think about security. If you don't put spooky files in ./public, then you don't need to worry about spooky things. Simple. So let's partition a public directory using app.use.
On line 3 I added a line that will serve a static file-system. That's one of express' built-in helpers. So now all you have to do is create a folder named "public" in the same directory as the server, and you can use this in production for static web-sites. But that's very boring. I realized that, rather than concerning about POST, PUT, DELETE, and anything except GET is frivolous anymore. Instead, I use Socket.IO for IO (instead of AJAX/GET/POST/PUT/DELETE and hundreds of files- I just think about x number of channels, each with incoming/outgoing emits and outgoing broadcasts), and GET for the initial page. I, personally, prefer to develop for HTML5/CSS3/ES5 than I care to worry about older or partially supporting browsers. You never need to send attachments anymore, as you can just send the file through a web socket, and use the local filesystem API to allow users to download files on the fly. That's only one of hundreds of use-cases for HTTP that can be done with less effort using web sockets.
Well, at the moment web socket support is beginning to become consistent, but for a while there every version of Chrome I installed broke my web socket application. I decided web sockets weren't for me, but then I rediscovered Socket.IO. Socket.IO will stubbornly try to make your sockets work in situations as ugly as IE5.5. Why, I don't know.. But if you're trying to target the most up-to-date browsers, socket.IO is nothing of a downfall- it certainly tries to use the best possible case for your browser. Whether it will or not, I don't know and don't care- but I do know that even browsers that support web sockets, the protocol was very hard to match across browser a year back. So for a full year, I haven't tried implementing my own sockets- Socket.IO is the cream of the crop for me, but you can do whatever you like.
Well, I made a little utility for Node.JS which uses Socket.IO and express, and I'm thinking of improving the DB with Mongodb, but many developers are using MySQL, MSSQL, basic JSON and various other things instead of Mongodb. There are lots of people trying MongoDB, and I encourage the use of that over the alternatives. I think Node.JS technologies are beginning to pass the test of web-time.
Okay I uploaded a repo to github with a maintainable example server using a file system of web apps, socket.IO, and mongoDB all on top of express.
(Information moved to github)
To be continued...
Make sure everyone gets a copy of Node.JS, and NPM (node package manager) so that it's trivial to install packages such as express, socket.io, mongodb, and more!
I'm making some pretty cool stuff with node.js, and I'll be sure to post some code examples/tutorial later on.
I'm hoping the community here at RZ may help me to gather up a good bundle of information for Node.JS.
Okay. Anyone who's gone so far as to download Node.JS has probably tried this famous HTTP server example from nodejs.org:
PHP:
var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World\n');
}).listen(1337, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');Okay, so let's do a similar thing with express:
PHP:
var express = require('express');
var app = express();
app.get('/', function (req, res) {
res.send('Hello, World!');
});
app.listen(8000);
console.log("Server is listening on port 8000.");
You must be registered to see links
you will see 'Hello, World!'. But if you visit
You must be registered to see links
you will see something like 'Cannot GET /foo' because express fails a little safer than and is a little more helpful for HTTP than the built-in HTTP module is.If you don't have express installed, but you do have npm, you can (in your command prompt/terminal) type: "npm install express" to install express.js!
So, there's no immediate proof that express solves the callback problem, so let's dig a little deeper. At the moment you may be thinking: What exactly does S-p-n mean by "Callback Madness"? That node.JS example looks easy- perhaps just as simple as express.
So let's try to make the Node.JS HTTP module example server listen on '/'- just like express module is doing.
PHP:
var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
switch (req.url) {
case '/':
res.end('Hello World\n');
default:
res.writeHead(404);
res.end('Could not GET ' + req.url);
}
}).listen(8000);
console.log('Server running at http://localhost:8000/');Okay, not so bad, but there's already a noticeable complexity problem arising under our nose. What happens if we want to add more requests? What happens if we want to host a file server like many other HTTP servers do? Well, there's modules to help us with that, but there's even better modules that do most of the heavy lifting for us.
Don't get me wrong, I tried to make a sustainable Node.JS file system module, and a sustainable Socket.IO module already- I don't give up that easily. And it's really not that I gave up, it's that there are people spending just as much time on express as I am on my custom stuff (well, probably more). Using the HTTP library you would need to include the 'fs' library or similar, and you'll have to do some crazy heavy-lifting like I did to make a good file-server with gZip compression and so on. Actually, it's probably a good 50 lines of JavaScript- possibly more if you want to add any cool dynamic magic to the mix. That's not too bad, so it's possible to scale Node.JS into a maintainable production-level server. But there's already an easier way.
Here's how to host a file-system in express:
PHP:
var express = require('express');
var app = express();
app.get('/', function (req, res) {
res.send('Hello, World!');
});
app.get('/:file', function (req, res) {
res.sendfile(req.params.file);
});
app.listen(8000);
console.log("Server is listening on port 8000.");Notice there's no callback madness- the deepest level is still 1 tab
So now it's possible to load the server file, I named mine 'test.js' so when I visit
You must be registered to see links
I get the code above. Now, you're probably thinking all sorts of red security flags right now. Well, you have good reason. Not many people want to push their server-side code to the browser. But it gets worse- well, it would get worse, but express protects us from even more evil scenarios such as this command:
Code:
curl http://localhost:8000/../passwd.txtWe are certain our server-side code is available, and we can make just as certain the files are safe by placing the file-system we want to serve in a public directory. It's no surprise files from ./public are going to be public, so it's a little easier for web developers to think about security. If you don't put spooky files in ./public, then you don't need to worry about spooky things. Simple. So let's partition a public directory using app.use.
PHP:
var express = require('express');
var app = express();
app.use(express.static(__dirname + '/public'));
app.get('/', function (req, res) {
res.send('Hello, World!');
});
app.listen(8000);
console.log("Server is listening on port 8000.");On line 3 I added a line that will serve a static file-system. That's one of express' built-in helpers. So now all you have to do is create a folder named "public" in the same directory as the server, and you can use this in production for static web-sites. But that's very boring. I realized that, rather than concerning about POST, PUT, DELETE, and anything except GET is frivolous anymore. Instead, I use Socket.IO for IO (instead of AJAX/GET/POST/PUT/DELETE and hundreds of files- I just think about x number of channels, each with incoming/outgoing emits and outgoing broadcasts), and GET for the initial page. I, personally, prefer to develop for HTML5/CSS3/ES5 than I care to worry about older or partially supporting browsers. You never need to send attachments anymore, as you can just send the file through a web socket, and use the local filesystem API to allow users to download files on the fly. That's only one of hundreds of use-cases for HTTP that can be done with less effort using web sockets.
Well, at the moment web socket support is beginning to become consistent, but for a while there every version of Chrome I installed broke my web socket application. I decided web sockets weren't for me, but then I rediscovered Socket.IO. Socket.IO will stubbornly try to make your sockets work in situations as ugly as IE5.5. Why, I don't know.. But if you're trying to target the most up-to-date browsers, socket.IO is nothing of a downfall- it certainly tries to use the best possible case for your browser. Whether it will or not, I don't know and don't care- but I do know that even browsers that support web sockets, the protocol was very hard to match across browser a year back. So for a full year, I haven't tried implementing my own sockets- Socket.IO is the cream of the crop for me, but you can do whatever you like.
Well, I made a little utility for Node.JS which uses Socket.IO and express, and I'm thinking of improving the DB with Mongodb, but many developers are using MySQL, MSSQL, basic JSON and various other things instead of Mongodb. There are lots of people trying MongoDB, and I encourage the use of that over the alternatives. I think Node.JS technologies are beginning to pass the test of web-time.
Okay I uploaded a repo to github with a maintainable example server using a file system of web apps, socket.IO, and mongoDB all on top of express.
You must be registered to see links
(Information moved to github)
To be continued...
Last edited:
