Last time, I wrote about how I was messing around with MongoDB ( = link_to_page 'MongoDB in a Deployed Environment' ) and how I had gotten it in a deployed state. However, I failed to cover my reasons for doing so. Why would I need to deploy MongoDB if I was only "messing around"?
The answer is my latest Ruby library: Mongolytics. As you can probably surmise, the name is a combination of MongoDB and analytics. You would be correct in guessing so. The interesting thing about Mongolytics, aside from its use of MongoDB is that the analytics are tracked on the server side of the request/response cycle.
I needed something to track not only page requests, but actions in Rails which may or may not have associated unique URIs. An example of this would be a create action. Typically, in a resourceful controller and in REST principles, a successful create should redirect to the newly created resource. This is most likely a show action.
This solution provides a few benefits. Speed, first and foremost. The results of any request instantly present a query-able statistic. This leads to the second benefit. The entire history of our statistics are permanently and easily accessible through a MongoMapped class.
There are three main parts to using Mongolytics (aside from setting up MongoMapper ): include the module, tell it what actions you want to track, and when some stats have been tracked we can turn around and retrieve them. Here is what that might look like:
Include the Modulemodule gist
Track Actionstrack gist
Check the Statsstats gist
And that is it. MongoDB will store all that stuff and make it easy to pull back out again. I tried to make it as quick and painless as possible. There are more options, including tracking session variables, that I will get to in another post (with a real example). In the meantime, please check out the project and README on Github and please tell me what you think in the comments.