I’ve made updates to my Ember Data Adapter for Parse. The example now has a more complete application and implements a few more views to demonstrate creating, reading and updating models. It’s all implemented against the Ember.js 1.0 RC1 and the latest from the Ember Data project.
A point I wanted to make with this project is that I could continue to use Parse with Ember.js. This in my opinion has a huge up-side: No need to write my own server/API/persistence implementation. In other words – no Rails. Now I’m not saying I don’t like Rails, in fact I’ve used Rails a lot and even got paid to do so for a while. What I’m saying is I’d rather not have to. At least at first.
There is a big up-side to only needing to worry about the client-side. This means to me that I have an API built for me that “just works” and I have an implementation on the server-side that I don’t have to work on or worry about. All that is left is to work out the real problem: The application itself.
In my opinion the application is usually the very last thing I get to work on because I spend so much time and effort on building up all the infrastructure. Pick a runtime, pick a framework, pick a database, pick an ORM, pick a host, setup the project, work out the deployment and then write the code for the API … and I’m spent. Phew. Didn’t even get to the UI, the client-side framework or let alone persistence layer. Oh geez – I forgot TDD there.
My point is just use Ember Data Adapter for Parse. At least in the beginning of developing your application. Maybe not forever, but at least at first. And if you end up really really wanting to use your very own Rails API … go on with your bad self!
Go take a look – http://clintjhill.github.com/ember-parse-adapter/