ember.js and the server

Question

I'm looking at Ember.js and have been reading the docs to try and understand how to use it. I get it (pretty well), except for one thing. To my way of thinking in the MVC pattern, the Model is the repository for data in the application. I can see how that works for client side data in Ember.js. What I don't get is how to tie that data back to the server so that if data changes at the client, the changes are updated in server. And vice versa. I've been doing this by in in my web applications making Ajax/JSON calls to back and forth to the server, I'm just not getting how to do that using Ember.js.

Solution 1

Digging just a bit around emberjs on GitHub I have found this: https://github.com/emberjs/data:

Ember Data is a library for loading models from a persistence layer (such as a JSON API), updating those models, then saving the changes. It provides many of the facilities you'd find in server-side ORMs like ActiveRecord, but is designed specifically for the unique environment of JavaScript in the browser.

I'd also suggest reading Ember.js Live Collections. What you want is to have a collection of models that will know how to sync with server side, possible example code is:

// our model
App.Person = Ember.Object.extend();

App.people = Ember.ArrayController.create({
  content: [],
  save: function () {
    // assuming you are using jQuery, but could be other AJAX/DOM framework
    $.post({
      url: "/people",
      data: JSON.stringify( this.toArray() ),
      success: function ( data ) {
        // your data should already be rendered with latest changes
        // however, you might want to change status from something to "saved" etc.
      }
    });
  }
});

You'd then call App.people.save() at needed occasions.

Also be sure to check out this article, Advice on & Instruction in the Use Of Ember.js, that goes deeper into server-client communication with Ember and also mentions emberjs/data.

Note: Emberjs Data Library should be used with caution for the fact that it is not production ready.

Solution 2

In Ember.js, the "model" contained in the Ember object will contain a further abstraction of an underlying server side database, if you're using one. The controller portion of the application then should have methods which allow you to retrieve and send data which are called when needed in order to update the model (using Ajax). This is nice because you have a model which can respond quickly on the client side to any input a user provides the application (keystrokes, mouse movements, whatever) and selectively choose when to make relatively costly queries to a server side database, for example. This way some of the performance of the app is no longer hindered by the latency of data requests to an an external server, which in some cases can allow you to create applications whose responsiveness approaches that of native apps.

Solution 3

I like to picture Ember.js in pairs like this

• Views and Templates are correlated (obviously), tweak the Views-Class to control the Template (like the classNames)
• Router and Routes work a bit like the controller in MVC. They are responsible for routing the request to the correct endpoint
• Controller and Model are model centric, one (the Model) describes the data you will handle in your application while the controller behaves like a kind of proxy (or decorator, if that's more up your alley). Templates will hook up to the controller for example and

Basically that means you load up your controller (single or array) with a model and can now easily model the processes working on that model (i.e. the stuff that does not touch the model in its core/data) in your controller. For an example blog application you would describe the Post in the model and add something like that for the controller

App.PostController = Ember.ObjectController.extend({
  content: null,

  // initial value
  isExpanded: false,

  expand: function() {
    this.set('isExpanded', true)
  },

  contract: function() {
    this.set('isExpanded', false)
  }
});

Now you can interact with the represenation of the model in terms of frontend thinking through the controller. Expanding a post or not does not change the model, only changing the data does.

In terms of reloading data from the server, I have two answers for you

1. I found this article quite helpful in understanding the connections (and simple polling, albeit simple)
2. If you're using Rails, you will get lucky with upcoming Rails 4 Live, see this post and demo for the juicy parts

Solution 4

I realize this is a bit old of a question, but it's on the highest-rated page for ember.js, so I figured I'd add a bit.

I've been using ember-model lately to handle RESTful data binding. It has fewer bells and whistles, but for my needs it's pretty decent. Basically, it just extends the model functionality to integrate reasonably well with a server pushing JSON objects through a standard REST interface.

View more solutions

Comments

[Misha Reyzlin]

DOM is Document Object Model and refers usually to the tree representation of HTML (or XML) elements and its API. In Ember.js model is most certainly not stored in the DOM and that is not such a good idea to store your data in DOM – DOM is the slowest part of JavaScript browser API. You could perhaps store bindings in DOM (like knockout.js does), but not the model itself. This is why all the shift from jQuery is being done at the moment – to not store the state of data and data itself in DOM.

[writes_on]

Thank you for the great answer, very helpful and the article you reference will be useful to me. In some ways the way Ember.js is used on the client side is kind of like the Mediator/Colleague pattern, which is useful for managing changes in dialog boxes of a GUI. Your hints above will help me pull that kind of thing together to keep the server/client in sync. Again, thanks a lot!

[theringostarrs]

@gryzzly - any article/discussion references to DOM being slower and problems with jQuery?

[Misha Reyzlin]

Maybe for your usage, jQuery and DOM are just fine! When I first read description of BackboneJS: “When working on a web application that involves a lot of JavaScript, one of the first things you learn is to stop tying your data to the DOM. It's all too easy to create JavaScript applications that end up as tangled piles of jQuery selectors and callbacks, all trying frantically to keep data in sync between the HTML UI, your JavaScript logic, and the database on your server. For rich client-side applications, a more structured approach is often helpful.” it matched exactly my thoughts.

[Misha Reyzlin]

While you can definitely write benchmarks (that's what I first did to reply your questions) comparing data setting and getting from DOM vs memory, it doesn't makes too much sense, it is all about the comfort of your team and maintainability of your product. So if DOM approach suits your needs and you don't feel the need to seek a better alternative, there is nothing wrong with that. However, when the app gets big, you start to realize that retrieving state of your application from classes or data attributes to update some unrelated node according to that state is not the most efficient way.

[Schmuli]

I think this answer should be deleted, as not only does it not answer the question asked, but I would say it contains clearly incorrect information. Some points: 1. DOM? There is no connection at all. 2. "the Server is the client", what? 3. How is performance related in any way to the OP's question?

[Peter Behr]

@Schmuli, you're totally right. I've edited the answer to be not false, and in any case there's a better answer above which answers the question directly.

[weia design]

I do not think ember-data should be put in the usage at the moment, since its clearly indicated that it is WORK IN PROGRESS and UNDER RAPID DEVELOPMENT part for emberjs. I think a stable alternative will be great.

[Misha Reyzlin]

@random the link to trek is definitely valuable there, it has a link to an old version of an article which is very educational and gives people idea of how to do client-server communication in ember. Putting it back.

[random]

You removed the direct link to the old version of the Trek article in favour of a page saying it's moved. Intentional?

[Misha Reyzlin]

@random yes, because that page also mentions the preferred way of doing this (via routers) over an outdated article – lets people choose if they want to check the old article anyway to learn or they will follow the new link