Node.js modules you should know about: socket.io | Hacker News Reader

Node.js modules you should know about: socket.io

catonmat.net

56 pointspkrumins17 comments

I do a lot of real time stuff, so socket.io is my favorite node.js module. It makes sockets so easy to use that I now use socket.io sockets (instead of regular sockets) for everything, which causes a problem because of lack of support for WebSockets outside of the browser. For example, connecting to a socket.io server from Android using Java. Fortunately, forked some code on GitHub (https://github.com/benkay/java-socket.io.client) and got it to work.

Got a question to y'all regarding the whole node.js stuff.

I downloaded ExpressJS framework and tried to create a simple MVC apps a'la Rails...

I get the impression that ExpressJS framework works better if you put the whole thing in app.js. Like... the whole code.

I tried to create another file other than index.js inside routes folder (let's call it something.js) so I can instantiate some JS controller code in app.js vs putting everything in one file. That doesn't work at all, "something" is undefined.

It turned out that I have to either put everything in app.js or in routes/index.js in order for ExpressJS to work correctly.

The whole experienced was... unexpected.

I'm kind of used to Rails MVC. So please tell me: am I using ExpressJS the way it shouldn't be used?

UPDATE: Thanks for the answers guys. Kind of what I would have guessed to hear => use module. Which is probably fine. Module in CommonJS does have a bit of bookkeeping beforehand.

I did have a bit of a hunch that I needed to know more about CommonJS and proper modern JS practices.

You can structure your code any way you wish. There are no rules on how you should write your webapp.

For example, you can break up your app.js and routes.js.

app.js:

    var express = require('express');
    var app = express.createServer();
    
    require('./routes')(app);
    
    app.listen(3000);

routes.js:

    module.exports = function (app) {
      app.get('/', function (req, res){
        res.send('Hello World');
      });
    
      app.post('/foo', function (req, res) {
        // ...
      });
    }

Or if it's a small app, you can just keep it all in app.js.

Thanks for the info. Next question for you (since I know you use a lot of Node.js). What's the recommended approaches for unit-testing your Node apps (Socket.IO, ExpressJS, whichever)?

What about switching between PROD, DEV, TEST environment like Rails? I found that feature is great since y'know... those environments will have different settings (I'm guessing the answer to this one is to roll your own kind of thing?)

About unit testing - I like expresso [1], but recently also started using tap [2].

[1]: https://github.com/visionmedia/expresso

[2]: https://github.com/isaacs/node-tap

Also see my startup that does javascript unit testing in all the browsers: http://www.testling.com

Now about switching environments, see this: http://expressjs.com/guide.html#configuration

And also see bouncy to route between production/development dynamically: https://github.com/substack/bouncy

There are a number of ways to do this but when I first started with node I started by using some different files which hold environment variables. You can then export some environment variables based on where you are running your code (production, dev, staging, etc)

For instance you might have a .production file

    export NODE_ENV="production"
    export NODE_PORT="80"

And a .development file

    export NODE_ENV="development"
    export NODE_PORT="3000"

Before you run "node app" just link to your variables with "$ . .production" or "$ sh .production"

Again there are many ways to accomplish this same thing but this way is pretty straightforward if you are familiar with linux.

EDIT: To add to the link to configuration pkrumins posted (http://expressjs.com/guide.html#configuration)

process.env will hold all of your environment variables, and express.js will read "NODE_ENV" internally. A combination of the above, and setting up corresponding internal configuration in your node.js app will provide for a very clean setup.

No. Keeping all your code in one file is a recipe for maintainability disaster. I've found that with Javascript, proper project organization is even more important than with some other languages.

It sounds like you haven't become familiar with Node's CommonJS compatible module system. Try starting there: http://nodejs.org/docs/latest/api/modules.html

Once you understand the basics of modules and requiring, I'd take a look at the ExpressJS example apps for organization ideas: https://github.com/visionmedia/express/tree/master/examples

Express is very flexible, and can work in just about any way you could imagine. Take no offense but it sounds like you aren't very familiar with javascript or node.js and that is okay, but there is much to learn about project organization.

It is actually quite easy to organize your code similar to a rails mvc application, the key is being consistent.

If you want to see a working example of an mvc style express application, then look at the examples provided with express: https://github.com/visionmedia/express/tree/master/examples/...

Again, there are many ways to organize your applications, just look around at what other people have done, or use the examples, and you should be able to make yours handle just the same.

This is one of the things that Rails gets right. There is no real need to be creative here. Rails just comes with a default layout built in, no need to 'choose your own' for the 'own' sake. It doesn't, btw, mean that you can't use your own, just in this case you'll need to add the relevant directories to the path yourself. The standard layout and built in generators are just brilliant.

Of course it is a matter of opinion, but you have to keep in mind that node itself isn't a framework like rails, and express while similar to sinatra with declaring routes is very un-opinionated about how it handles things. That is one reason I enjoy using node and a lot of the modules and add-ons created for node, giving me the freedom to do what I want from the start and not fight against the 'right' way the creators intended.

this is a common misconception about rails.

Rails doesn't "force" you to use their way. You don't have to call your table "people" if your model is called "person". It just that you have additional freedom not to configure anything if you are ok with the default configuration.

in many other frameworks you always have to configure everything, abut in rails you might just go with the defaults and skip the configuration altogether.

If express had code generators that would generate standard layout for models etc it wouldn't hurt anyones' ability to use their custom layout.

rails apps are also very large, making them annoying/difficult to bundle up with other modules such as the nodejs Kue module which uses express for the UI. Rails modularity is quite terrible, Drupal does this much better, but yes you have to be creative with Express, which is only difficult if you're not creative. Application requirements are significantly different, myself and many others prefer a "start small" approach vs the "start huge" approach.

you just need to learn how node modules work, this is a big issue for a lot of people but it's the result of node's module system, not express

Can anyone comment on how Socket.io and Faye* compare?

* http://faye.jcoglan.com/

This is the first time I hear about Faye.

http://stackoverflow.com/questions/4893720/faye-vs-socket-io...

The only thing that disappoints me about socket.io is that the client library is 40KB- I'm developing a mobile app and am trying to keep JS memory usage to a minimum (ZeptoJS instead of jQuery, etc) and socket.io's client lib is just so huge.

Is there a stripped down version of it, or some other wrapper library around websockets? I've been playing with just using the native stuff, but the different versions of API implementation are biting me a little.

Reply on news.ycombinator.com