Sorry, I didn’t notice that this had activity. The short answer is, yes, I was able to use Ember.js (and I absolutely love it).
The long answer is that I ended up writing a ReST API over the top of Neo4j. My application has 4 object types: users, graphs, vertices and data nodes. I created a ReST API that exposed basic CRUD operations for each of those 4 types of objects. From there, you can just use the ReST Adapter (or write your own like I did).
The hardest part about the whole thing is managing relationships properly. For instance, say that a vertex has 4 children with IDs [1, 2, 3, 4] and somebody sends a POST request to update the vertex so it has children [3, 4, 5, 6, 7, 8]. Essentially, you have to do a diff on the two sets, then create and destroy relationships in Neo4j as necessary. It’s a bit unintuitive to think of modifying graphs this way, but it makes things a lot easier when interacting with other technologies. (There isn’t a whole lot of graph database usage out there yet.)
My advice would be to do this:
- From the user point of view, come up with all of your domain objects. Users, documents, trees, vertices, etc. Flesh them out in Ember-Data models with all of the properties you want them to have.
- Figure out how the objects relate to one another. Using the hasMany() and belongsTo() relationships, tie your objects together in a way that makes sense from the client perspective. (Also, one-to-none and many-to-none relationships come in very handy. Just set the explicit inverse to null.)
- Build your application using the Fixture adapter. Your object model is going to change quite a bit, so don’t you dare write any persistence code until it’s been through a few revisions.
- Design your API. You can either design it with the Ember-Data ReST adapter in mind, or you can design it from scratch and write your own adapter. As you’re designing it, follow the usual good practices, but just keep in mind CRUD.
- Now that your application works and you have a valid API, NOW you may write the persistence code. It’s going to be a pain in the butt to wire up your ReST API to the Neo4j API, but it’s worth it. Much better to have that translation on the server side in statically typed language than on the client side.
That’s what I did for my original application, and it worked out well. In fact, I’m currently repeating this process again for an application at work. I’m currently on step 4. And we’re actually using a content repository (JCR) this time around, but if you follow the steps above, you’ll have a great abstraction layer over the DB, so it won’t matter what you’re using.
Anyway, I hope that gives you some direction. The gist of it is that you should start from the front end and work to the back-end. Neo4j has some incredibly powerful features, you’re just going to have to abstract them a bit so they can fit in with the current relational/object database idioms.