Lets start with the obvious: MongoDB (Ruby Driver) hits the sweet spot in the NoSQL field for web apps. It has more flexibility then a traditional RDMS and scales horizontally with relative ease, but it is also more user friendly then key/value stores which require you to implement by hand many of the features one might take for granted, like indexes and queries.

Having said this, there is still a need for an ORM layer if one wants to create the model layer efficiently. In this post I am going to relate my experience with the two most popular Mongoid by Durran Jordan and MongoMapper by John Nunemaker.

Mongoid

Mongoid is the more recent of the two libraries in this article, but from a users perspective, it is now the furthest along. It has adequate documentation, but I still find my self mucking around in the code looking for more information. Mongoid tries to follow the ActiveRecord way of doing things, which is appropriate given that AR is by far the most used ORM in the wild. On the other hand, I am not particularly fond of the ActiveRecord paradigm and having seen several other ORM's like DataMapper or Sequel I find the API a little Awkward.

Mongoid also sticks more closely to the underlying driver. This has it's good and bad points. One for the reasons for choosing a data store like MongoDB is because it gives you tools that other solutions don't. By sticking close to the driver, more of this tools become accessible. On the other hand, it can, and in this case does, lead to an impedance mis-match in the API. Many methods pass their options straight to the underlying driver,but do so in ways that are not obvious and undocumented. When something goes wrong the cause is often hard to track to its source, and the documentation is not yet complete enough to explain what's going on.

MongoDB as a document oriented system, allows for complex documents to be stored as records. These records need not all be structured identically, and sub-documents are common and valuable features. Mongoid does a better job of exposing and dealing with this functionality. Embedded documents are obvious, flexible and sensible. I would like to see native support for a Hash datatype. It is also more difficult then necessary to add or manipulate key/value pairs that are not declared as fields.

Finally, it is good to note that Mongoid comes with excellent integration for Rails 3 and its generators.

MongoMapper

Coming from the DataMapper world, MongoMapper seemed like an excellent fit, and my hope is that it will be some time in the future. At the moment the library code seems decent, but the lack of any meaningful documentation is a deal killer. Even someone on a schedule as unhurried as mine, cannot afford to spend most of their coding time reading source code fro their libraries.

Having said that what I have been able to learn for perusing the code, reading Mr. Nunemaker's blog, and console introspection is impressive. The query builder syntax follows the very intuitive and efficient pattern developed in DataMapper. Unfortunately, the API hides a little too much of MongDBo's power. This make it hard to, for example, use MongoDB to perform atomic updates. The read, modify, save pattern is not a great fit for MongoDB as it lacks transactions.

MongoMapper is also a little peculiar in that it has a separate class for top level documents and embedded documents. This seems to be unnecessarily complicated. On the other hand I found a smoother interface in MongoMapper's mapping of JSON structures into Ruby objects.

Finally, there is simply not as much development going on with MongoMapper. I expect that this is simply the usual ebb and flow of an open source project, however.

Conclusions

At the moment, I'm using Mongoid because I need a documented library that I can get things done with. I think MomgoMapper has the potential to be the stronger paradigm but it will need some time and effort that I would like to put into other places. Both libraries are worth keeping an eye on over the next six months.