Officially, ember-data is in beta, which means (they think) they've stabilized the API for 1.0 and are finding and patching bugs. This sounds nice, but they're currently on beta 8, and the first beta was tagged on September 1 of 2013. (There's a blog post from March which promises 1.0 is "coming soon"™.) So some of the issues described below may have improved, but others aren't going to improve until the 1.0 comes out of beta and the core team addresses them in point releases (or, worse, 2.0, which seems infinitely far in the future).
- Nested data: This is any time an object has child relationships explained by the route (i.e.
/posts/1/comments). This is doable but may require some fancy footwork on the Rails side to ensure the application sends JSON to the Ember application in the way ember data expects. - Relationships: It's apparently non-trivial to ensure related records are appropriately referenced and loaded once they've been sent to the Ember application. (So, in the above example, if we requested
/posts/1and then associated comments at/commentswe might need to do additional steps on the Ember side to ensure the relationships were established.) - Pagination: If the record sets returned by the API are large and need paginating ("send me 20 records instead of 5,000") there is much more noisy discussion back-and-forth with the API for each page, and organizing the metadata on the server side is required. This also tends to break customized sorting. This was a huge pain point at BeQuick.
For the calendar I'm not sure pagination and sorting is going to be an issue. Nested data and relationships might be, but if we find ourselves getting too deep with ember data, one of the alternate libraries (e.g. ember-resource, ember-graph) might resolve the problems. Ember-graph in particular could be promising for our data model.
Some posts:
- Best practices for web service design with ember data - "Either denormalize your database to match what ember data expects, or let ember data make its requests and use server-side scripts to translate that to the correct database queries."
- Nested API resources are a pain - Nested resources were a major source of pain for our API at BeQuick. Looks like using links in the JSON returned from the server is the best approach. This is still a big problem.
- Endless frustration is a year old but enumerates some pain points, and the responses describe some approaches to mitigating them. In particular this one talks a lot about relationships.
- Pagination: Can we agree on a single solution?
- Discourse does a lot of resource loading using straight-up
$.ajax()calls. - ember-resource is from Zendesk, and is very mature (pre-dates Ember 1.0).
- ember-model is also pretty mature, from Ember core team member Erik Bryn.
- ember-graph (introduced in this post here) is shiny-new and still in very active development. Not yet 1.0 but in use in production.
- ember-orbit (introduced in this talk at Wicked Good Ember - the back of my head is visible at bottom left) is an Ember wrapper for Orbit.js and seems to be optimized for coordinating access to multiple data sources.