Yesterday, we gave you an update on our progress making Ember.js easier
to use. One thing we didn't discuss was our plan for Ember Data.
It's no secret that, while many developers are building awesome apps
with Ember.js, Ember Data still causes lots of frustration due to bugs
and a changing, complex API. Documentation about it is also mixed in
with Ember.js documentation, making it difficult for new developers to
understand what is stable and what is not.
To be clear, Ember Data is not a dependency of Ember.js.
Discourse, for example, uses
its own wrapper around
$.ajax.
Even though Ember Data is not a dependency of Ember.js, loading data
from the server is an extremely important part of most web applications,
and it's a problem that every Ember.js application will have to deal
with.
Our long-term goal is as follows: we don't think most web developers should
have to write any custom XHR code for loading data. Strong conventions
on the client and strong conventions on the server should allow them to
communicate automatically.
We know we're not there yet.
In order for this to work, there are many necessary features that must
be rock-solid across all sorts of different persistence layers—local
storage, relational databases, and key-value stores, to name a few. To
top it off, the asynchronous environment of the browser (with an often
unreliable internet connection) adds significant complexity, and means
we have more to do besides porting solutions to these problems that have been
pioneered on the server.
Getting all of these features working well together is a challenging
problem, and we have not been able to deliver everything we thought we
could in a reasonable amount of time.
Additionally, many developers are writing web applications that need to
consume an existing JSON API that evolved organically and is not
consistently named or structured. The API we have provided so far is
suboptimal for this task.
To make the experience of writing an Ember Data application less
frustrating, we're doing two things:

1. We're identifying a subset of features that already work reliably.
2. We're introducing a new, simpler API for working with remote data
   that makes fewer assumptions. You still get to use the model API
   in Ember Data, but can "bring your own $.ajax" to load and store
   records.

Right now, what gets documented is somewhat ad-hoc. Going forward, we
will heavily document the stable features. Finding documentation about
an Ember Data feature on the emberjs.com website will be your indication
that we consider it stable and safe to use.
Over time, after we have put new features through their paces and
written extensive documentation, the set of stable features will grow.
In other words, we are refocusing on a small core of practical features,
which we will slowly iterate towards our long-term, ambitious goal.
The Basic Adapter
The Ember Data adapter layer, which is responsible for finding and
saving records, is currently designed to help with building reusable
adapters, like the ones people have written for
Parse or
CouchDB. It is not
well-suited for delegating out to $.ajax to work with an API
that is not 100% consistent.
To make it easier to use Ember Data with any kind of JSON data, we
are introducing the Basic Adapter, which delegates to a sync
object on your model.
Let's look at an example of using the Basic Adapter with the Twitter API.
First, note that the syntax for defining a model hasn't changed
(historically, this has been one of the most stable parts of Ember
Data):
var attr = DS.attr, hasMany = DS.hasMany, belongsTo = DS.belongsTo;

App.User = DS.Model.extend({
defaultProfileImage: attr('boolean'),
description: attr('string'),
screenName: attr('string'),
isVerified: attr('boolean'),
createdAt: attr('date'),

tweets: hasMany('App.Tweet')
});

App.Tweet = DS.Model.extend({
coordinates: attr('point'),
createdAt: attr('date'),
isFavorited: attr('boolean'),
retweetCount: attr('number'),
text: attr('string'),
isTruncated: attr('boolean'),

replyTo: belongsTo('App.User'),
user: belongsTo('App.User')
});

Finding records also hasn't changed:
// use the Promise API
App.User.find(userId).then(function(user) {
return user.get('tweets');
}).then(function(tweets) {
// do something with `tweets`
});

When you request the User and then its tweets, Ember Data will make
calls to your models' sync object.
App.User.sync = {
find: function(id, process) {
$.getJSON("/users/show", { screen_name: id }).then(function(user) {
process(user)
.primaryKey('screen_name')
.camelizeKeys()
.applyTransforms('twitter')
.load();
});
},

findTweets: function(user, name, process) {
var screenName = user.get('id');

$.getJSON("/statuses/user_timeline", { screen_name: screenName }).then(function(timeline) {
process(timeline)
.primaryKey('id_str')
.camelizeKeys()
.applyTransforms('twitter')
.munge(function(json) {
json.isTruncated = json.truncated;
json.replyTo = json.inReplyToScreenName;
})
.load();
});
}
};

As you can see, in each of the hooks on the sync object, the last
argument passed in is a function called process. You use this function to
load JSON data returned from the XHR into the store. It also includes
several conveniences for common transformations, like camelizing
property names and transforming values like dates.
Note that you are not required to use these conveniences. You can write
whatever imperative code you'd like to transform the JSON returned from
the server into the form that Ember Data is expecting. Here is the above
example re-written without using the chained conveniences.
findTweets: function(user, name, process) {
var screenName = user.get('id');

$.getJSON("/statuses/user_timeline", { screen_name: screenName }).then(function(timeline) {
var tweets = timeline.map(function(json) {
// Map primary key
json.id = json.id_str;

// Camelize property names
for (var prop in json) {
var value = json[prop];
delete json[prop];
json[camelize(prop)] = value;
}

// Convert string-formatted date to object
json.createdAt = Date.parse(json.createdAt);

// Convert hash to JavaScript object
json.coordinates = new Twitter.Point(json.coordinates);

// Rename properties
json.isTruncated = json.truncated;
json.replyTo = json.inReplyToScreenName;

return json;
});

process(tweets).load();
});
}

Timeline
We have been working on this new API part-time for the past few weeks.
You can see our progress on Ember Data's master branch, by looking at
the tests or the implementation.
Over the next few weeks, we will be writing documentation that will be
available in the Ember.js Guides. Once a
few people have had the opportunity to use the Basic Adapter and
sanity-check our work, we will start cutting beta releases of Ember
Data. We think that this will be a lot easier for new developers than "make
a build from master."
Our thanks go out to John McDowall, who has been
tracking our progress on Basic Adapter and writing documentation to go
with it.
Finally, we'd like to give a big thanks to
Addepar for financially supporting us
while we do this work. They are big users of and contributors to Ember
Data, and we couldn't do it without them.