Nice article, quick and easy to get through and... I'm sure actually doing this is much better than when I tried this as both have matured quite a bit but... This article is a nightmare of mine, having to use both Nodejs and MongoDB together.
That said, if your project doesn't store extremely important data and needs to be quick to write Mongo's an OK choice.
Of course, even though it's much easier to use than other databases at first, if you later want to make sure your data doesn't disappear it's a total PITA.
Mongo is cool, and Mongoose (node ORM-like wrapper) is pretty nice as well, but after using it for a few months on a project I was building I realized that I was duplicating a ton of data. Until mongo solves the issue of joins (something that is better suited to a sql solution), I just had to revert and ended up used node-mysql which is a pretty decent node mysql driver. I was considering using mongo for sessions (with connect-mongo), but ended up going with redis as it's pretty solid solution (and according to some benchmarks, faster).
It's not supposed to be a big deal that you're duplicating data. If you want to get the most out of a "document store" like mongodb, you've got to get yourself into a certain frame of mind.
Don't think they're going to 'solve' the issue of joins. I think they've taken the decision not to support them. It then becomes an issue of denormalisation, and whether you can actually work on a project with everything denormalised. Otherwise there are some alternatives out there that support joins.
I struggled with the concept of denormalisation, as I came from a hobbyist SQL background, but I managed to build a project based on Mongo and Node (https://rwt.to), and in the process I went from trying very hard to 'make joins work' to hitting the sweet spot of getting my data 'right'. Mongo certainly ain't meant for everything, and I don't know if they'll ever support joins.
Yeah my site is more social-oriented so I can see how your site may work better with something like mongo (if it's mainly lat/long coordinates). Just as a quick example of something I ran into: When saving comments I liked to save the user's _id, username, along with their avatar so I wouldn't have to do a join later on, but then realized what if the user changes their avatar? Since I store the avatar as a row in the `users` collection, then I'd still need to do one of those nasty fake joins.
The post/pre-save methods are pretty bad ass and there are a few things I still do like about mongo (which is why I chose to explore it initially), but I think for social type websites, a sql solution makes more sense. I also scoped @ http://www.rethinkdb.com/ which looked interesting, but at this time I wanted to go with a more bulletproof solution to my problems.
One way that I keep my data up-to-date is that when I change something in my "station" data (let's say it's an avatar equivalent) I have an update that's triggered across my "route" collection. So you would likely have to do the same. It works well for me, as the reality is that there's always going to be something that changes and needs to be updated. That's why Mongo has decent update queries.
I feel you - I recently started a node project on LevelDB and ultimately switched over to an SQL database. The difference though is I went for Postgres 9.3, which has incredible native JSON support, allowing you to slice parts of your JSON data out as a record set, join them against tables, as well as other crazy things like partial indexes on deeply nested JSON values which may or may not be present.
I really think Pg is starting to blow Mongo out of the water.
I'm a big fan of ORMs in other ecosystems (Rails and Django, for example), but in node I like to write more functional-style code, composing small modules into larger applications.
For this, check out the fantastic node-postgres adapter from brianc as well as his node-sql package for authoring SQL statements.
The 'pyramid of doom' is one of my pain points with node right now. The article's solution is to push the anonymous functions out into separate named functions, but this just adds more code. Would have been awesome to use promises instead.
The async library (https://github.com/caolan/async) offers many excellent tools for staying out of callback hell. After using it one project, I can't imagine trying to write heavily async javascript without it.
All I have to say guys; promises + generators. My god, it's absolutely delicious.
Seriously, just learn it. Get your --harmony flag on. It will be in browsers soon enough as well. It's literally the future of javascript and having converted some of my codebase to promises + generators instead of just promises. Wow. It felt amazing. Suddenly everything doesn't look like spaghetti.
I use bluebird for promises and a custom dev fork of Coffeescript that allows for generators. You do have to wrap your anonymous functions with "Promise.coroutine", but thats really it. You could always just not even use promises, and go plain generators too.
If I promisify some code with bluebird, can I use it with Mongoose's built in promises? Or will promises from different libraries explode when they touch?
Well promises are suppose to be compatible with one another due to adhering to rules. Should be A-OK. Bluebird is just, at the moment, the most performant Promise library, and they seem to be building their API as close to what native Promises will be like. You could really use any promise library and it wouldn't matter much, perhaps use the one that mongoose uses if it's an issue.
IMPORTANT: the current stable official node-mongodb-native silently wraps exceptions. So completely non DB related code might be failing in your app, but because it's called in a callback, it won't ever show up.
23 comments
[ 0.27 ms ] story [ 57.8 ms ] threadWhy? I still can't get this out of my mind:
https://twitter.com/HackerNewsOnion/status/38257854706983731...
Also before anyone gets too serious with a reply, learn to laugh. Humility goes along way! I poke fun at Ruby/Rails all the time.
That said, if your project doesn't store extremely important data and needs to be quick to write Mongo's an OK choice.
Of course, even though it's much easier to use than other databases at first, if you later want to make sure your data doesn't disappear it's a total PITA.
I struggled with the concept of denormalisation, as I came from a hobbyist SQL background, but I managed to build a project based on Mongo and Node (https://rwt.to), and in the process I went from trying very hard to 'make joins work' to hitting the sweet spot of getting my data 'right'. Mongo certainly ain't meant for everything, and I don't know if they'll ever support joins.
The post/pre-save methods are pretty bad ass and there are a few things I still do like about mongo (which is why I chose to explore it initially), but I think for social type websites, a sql solution makes more sense. I also scoped @ http://www.rethinkdb.com/ which looked interesting, but at this time I wanted to go with a more bulletproof solution to my problems.
I really think Pg is starting to blow Mongo out of the water.
0 : https://github.com/tgriesser/knex 1 : https://github.com/tgriesser/bookshelf
For this, check out the fantastic node-postgres adapter from brianc as well as his node-sql package for authoring SQL statements.
https://github.com/brianc/node-postgres https://github.com/brianc/node-sql
Supports joins out of the box, and has much saner locking. It is in its infancy still, but I believe are coming out with a LTS release shortly.
Also, it's just fun to work with.
Seriously, just learn it. Get your --harmony flag on. It will be in browsers soon enough as well. It's literally the future of javascript and having converted some of my codebase to promises + generators instead of just promises. Wow. It felt amazing. Suddenly everything doesn't look like spaghetti.
I use bluebird for promises and a custom dev fork of Coffeescript that allows for generators. You do have to wrap your anonymous functions with "Promise.coroutine", but thats really it. You could always just not even use promises, and go plain generators too.
This is acknowledged by 10gen/MongoDB inc: https://groups.google.com/forum/#!topic/node-mongodb-native/...
Use the beta 1.3 driver until 1.4 comes out unless you want to tear your hair out.