Is Ember.js right for me?

1

I’ve been struggling with Ember.js for a little while, and I think the reason I might be struggling is that maybe Ember.js just isn’t right for my application. (Of course, it’s fairly likely that I’m just not getting it either.) But I was hoping that I would be able to get some direction by describing my application.

My application (in the back end) uses Neo4j for a database. Just like any graph, nodes have many relationships, and relationships connect two nodes. Some of the properties on the nodes are static (id, label, children, etc.), but many of them are dynamic and only exist on certain nodes. The property types are: string, number, boolean, string array, number array, boolean array. And because it’s a graph, changing one model can have affects on other models. (Deleting a node will also delete all of it’s adjacent relationships.)

All in all, the data model isn’t too complicated, but it’s certainly not common. Is Ember.js (including Ember Data) able to handle this kind of data model? I really love Ember.js, especially things like routing and the automatic configuration via naming conventions, but sometimes I feel like I’m trying to jam a square peg in a round hole.

Any advice on what to do would be greatly appreciated.

Thanks, Gordon.

2

Hi Gordon, I see that no one has answered your question. Have you been able to resolve your problems, or have you moved away from Ember.js? I’m also considering tinkering with both technologies and would appreciate any feedback.

Thanks, Chris.

3

Ember Data is meant for a relational database with a set schema. It sounds a little like a NoSQL kind of db you have there but I’m not sure what Neo4j is.

Do you have an example of schema for reference?

4

I would probably go with ember-model with this – you need to simply create a function for loading, saving and querying … ember data seems too relational for this.

5

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:

  1. 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.
  2. 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.)
  3. 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.
  4. 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.
  5. 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.

2 Likes
6

@gordon_kristan, thanks this helpful “getting started” guide! :smile:

Now that it’s been almost two years, do you have any further advice for someone going down the same path with Ember, Neo4j and possibly a Rails API?

1 Like