4

I'm finishing up building my first site with node.js and I'm curious if there is a checkoff list for all the things that I should complete before I get it up. In development when certain values are not expected in my database calls, (using Mongoose), my site will just die (e.g. node segfaults).

I'll also be using this on a VPS of mine that already have Apache installed on it, so will I be able to run both or do I need to look into something else for that?

Basically once it's up, I want to keep it up, and I'd like to know of any standard precautions I should know of before doing so.

Thanks!

bob_cobb
  • 2,229
  • 11
  • 49
  • 109

2 Answers2

4

I'm currently in a similar situation (about to deploy my first app on a private VPS), and here is the list I came up with:

1- Error logging: I used a simple WriteStream here, nothing too fancy.

var fs = require('fs');
//You might want to specify a path outside your app
var file = './log.log';
var logger = fs.createWriteStream('./log.log');
app.configure(function(){
    //...
    app.set(express.logger({stream:logger}));
    /...
});

2- Use Forever to ensure that your script will run continuously. Yes, they are plenty of other solutions (using a daemon, for example), but I've been using forever for a while now, and never had any problems.

3- Consider setting up an admin interface. This was actually a requirement in my case, so I went ahead with smog, which will look very nice, especially for your client :).

4- If you use forever, you can monitor its state using Monit. Check out this blog post for a basic setup.

5- If you are using Mongo, consider developing a backup strategy of your data. This page is a very good starting point.


Note that this list does not contain any information regarding multi-app, multi-machine or multi-core support.

If multi-app support interests you, nginx seems to be a trusted solution. This (brilliant) SO answer will help you get set up.

If you have many spare machines to use, node-http-proxy was developed by nodejitsu, and allows you to expose only one machine and reverse-proxy the rest.

If you are looking for multi-core support, cluster comes bundled with node, so you can spawn N different processes (N being the number of cores you have) and have them listen to the shared port.

And, since we all love to hear a nice story, here a few posts about nodejs/mongodb use in production and the lessons learned:
1- Lessons learned from launching i.TV
2- Using Mongodb for 2+ billion documents on craigslist

Community
  • 1
  • 1
verybadalloc
  • 5,768
  • 2
  • 33
  • 49
1

Given that Node.js is not a web server like Apache or IIS, there's no checklist of configuration settings to follow. Also, given that the modules and/or frameworks you use can vary widely based upon the project you are creating, checklists would always miss something...especially as the Node.js ecosystem continues to evolve and grow.

As such, I'd suggest reviewing the material here as they answer your questions and are generally useful no matter what you are doing with Node.js:

I am concerned that your app dies "when certain values are not expected in my database calls".

Mongoose is a nice tool because it allows for custom data validations on individual fields, can filter out data that doesn't fit into the Schema you have defined (keeping your documents consistent), and with the right settings can throw errors when there is 'bad data' passed to it rather than send bad data to the database, and more...

I'm wondering what you are doing that an unhandled error is making it pass Mongoose and past any callback function knowing that callbacks usually take the format function(err, data) and present the opportunity to deal with the error immediately.

Community
  • 1
  • 1
Matthew Bakaitis
  • 11,600
  • 7
  • 43
  • 53