5 ms·

I ran into the same issue the author describes, RE: getting Ember to work with a non-Rails-style REST API. After spending quite a bit of time trying to figure o

by endemic 13y ago

I ran into the same issue the author describes, RE: getting Ember to work with a non-Rails-style REST API. After spending quite a bit of time trying to figure out Ember Data, I reverted to Backbone, since it's dead simple to link a model with any API endpoint. All in all, a pretty frustrating experience.

mjallday 13y ago
Absolutely, there's a nice looking project for Ember called ember-model (https://github.com/ebryn/ember-model https://github.com/ebryn/ember-model) which looks promising for addressing this shortcoming.
- ulisesrmzroche 13y ago
  The main goal in that project is to provide primitives on top of $.ajax that are required by ember. Key thing to keep in mind is that it's just $.ajax under the covers.
  - mjallday 13y ago
    It looks like most of the complexity in ember-data is to do with transaction management and references. We decided to forgo both of those and haven't really lost anything because of that. It's opinionated way of dictating your JSON payload etc was also a factor in the decision to drop it. If you use RoR as a backend it's a perfect tho I assume.
    - ulisesrmzroche 13y ago
      Yup. It's about making sure that the data layer and the view layer are in sync. That's where it gets hard. Other than that, it's just $.ajax. ebryn's project is the wrapper so you can plug into that stuff. What you're losing is responsiveness in the UI. You're going to have to dictate when the call is made, and some may even be blocking. For stuff like submitting a form, or navigating to a new page, that's not a big deal, right? The user has to press a submit button, or the url changes, so then you handle the event. But once you're requirements are real-time, and data-intensive, (DIRTy) then handling all these events is really going to be a nightmare and that's where ember-data is great. Lots of folks knock ember-data, but it's pretty great if you're using it for real-time data intensive applications, which is really what this is made for.
      - mark_l_watson 13y ago
        I have experimented a lot with Ember.js but not used it for any serious projects. It took a while getting a grip on Ember-data. I don't know if this will help anyone but I took the example (front end only) code from "The Source for the Ember Get Excited Video", forked it on github, and added a trivial Ruby Sinatra REST service. It seems to work, but if you see any errors please let me know: https://github.com/mark-watson/bloggr-client https://github.com/mark-watson/bloggr-client
        ulisesrmzroche 13y ago
        I can give this a code-review later tonight. I'll contact you on github.
ulisesrmzroche 13y ago
In the end, ember-data calls are just wrappers for jQuery .ajax, so anything that ember-data can't handle out of the box, you can write yourself same way you do in Backbone.

by endemic 13y ago

mjallday 13y ago

Absolutely, there's a nice looking project for Ember called ember-model (https://github.com/ebryn/ember-model https://github.com/ebryn/ember-model) which looks promising for addressing this shortcoming.

ulisesrmzroche 13y ago
The main goal in that project is to provide primitives on top of $.ajax that are required by ember. Key thing to keep in mind is that it's just $.ajax under the covers.
- mjallday 13y ago
  It looks like most of the complexity in ember-data is to do with transaction management and references. We decided to forgo both of those and haven't really lost anything because of that. It's opinionated way of dictating your JSON payload etc was also a factor in the decision to drop it. If you use RoR as a backend it's a perfect tho I assume.
  - ulisesrmzroche 13y ago
    Yup. It's about making sure that the data layer and the view layer are in sync. That's where it gets hard. Other than that, it's just $.ajax. ebryn's project is the wrapper so you can plug into that stuff. What you're losing is responsiveness in the UI. You're going to have to dictate when the call is made, and some may even be blocking. For stuff like submitting a form, or navigating to a new page, that's not a big deal, right? The user has to press a submit button, or the url changes, so then you handle the event. But once you're requirements are real-time, and data-intensive, (DIRTy) then handling all these events is really going to be a nightmare and that's where ember-data is great. Lots of folks knock ember-data, but it's pretty great if you're using it for real-time data intensive applications, which is really what this is made for.
    - mark_l_watson 13y ago
      I have experimented a lot with Ember.js but not used it for any serious projects. It took a while getting a grip on Ember-data. I don't know if this will help anyone but I took the example (front end only) code from "The Source for the Ember Get Excited Video", forked it on github, and added a trivial Ruby Sinatra REST service. It seems to work, but if you see any errors please let me know: https://github.com/mark-watson/bloggr-client https://github.com/mark-watson/bloggr-client
      - ulisesrmzroche 13y ago
        I can give this a code-review later tonight. I'll contact you on github.

ulisesrmzroche 13y ago

In the end, ember-data calls are just wrappers for jQuery .ajax, so anything that ember-data can't handle out of the box, you can write yourself same way you do in Backbone.