] At this year’s annual Clash of the Coders, I teamed up with Steve Sparks and Mark D to create Krëndler, a framework that can be added to any iOS application to record and play back a user’s touch events. Steve and Mark took care of the iOS aspect, while I created an API for them to use to store the touch event data they collected.

The problem

Leading up to the competition, we discussed what the schema of the JSON sent to the server might look like. While we were able to brainstorm some possibilities, we didn’t yet fully understand the domain or what would make the most sense for storage. In the face of this problem, I saw two reasonable solutions.

First, I could go the traditional Rails route and use a relational database. Since I wasn’t sure what the schema would be, I would be forced to store it in a text column or possibly leverage PostgreSQL’s hstore until I knew enough to be able to create matching models/tables/relationships for the data.

Alternatively, I could use a schemaless database. It would make setting up dead simple, but would be limiting later in development if I needed to query on embedded documents.

MONGODB to the rescue

This application was a prototype developed in a very short timeframe, so I made the choice that benefits developer time and went with MongoDB, with mongoid as the ODM. The great thing about this choice was that I could set up an endpoint for the client-side guys to store/retrieve JSON dumps of their touch event data without having to know anything about the data they were sending. As I needed to access data, I could set up just the fields and relationships I wanted at that moment. Through this process, the schema and the application grew organically together. And now that the JSON schema has stabilized, I have the information I need to make a more educated decision about how the data should be stored.

The next time you find yourself prototyping an application, consider if the advantages of a schemaless database will help you develop faster. However, don’t get too attached to your prototype—while MongoDB can help you get running faster, don’t force it to solve a problem that would be better handled by a relational database.

Editor’s note: Want to learn more about APIs and iOS apps? Patrick Van Stee led a great Tech Talk on HTTP API design for iOS apps, covering best practices for modeling resources, tools to help build APIs, and production and deployment-related problems.