Hello,
I am in the process of designing the web service backend that our Ember-Data app will consume, and I have a few questions on best practices here. I did not find a related post, but if I missed it, please let me know.
Responses on many, all or just one of the below items are welcome!
1. Extensive Use of Database Views?
At first, I assumed the models in Ember-Data should basically match 1-to-1 with the tables in our database, but increasingly I’m seeing that my frontend is more of a “subset” of the entire data model than a total and complete reflection. This leads me to conclude that my back end (web service) should be returning a whole lot of database views, so that I can get exactly the data I want for reporting and other screens.
Is it common to make extensive use of database views, rather than matching the models 1-to-1?
2. Composite Primary Keys
Many of our entities on the backend could be designed to use composite primary keys where instead of a single id column as the primary key, the primary key would be a composite of personId, and versionId or something like that. But Ember-Data seems to prefer single-key primary keys, and the only way around this seems to be to write a custom adapter on a per-model basis, which seems kind of painful.
Is there a clean / streamlined way of handling composite primary keys in Ember-Data, or am I better off just using a single key primary key wherever possible?
3. Preventing the Local Store from Getting Overloaded
Our app will sometimes return thousands of rows of data for a given query. We’re throttling this by using pagination at every step so that while the database query might return 1,000 rows, the web service will return only 50 rows.
But let’s say the user keeps clicking through the pages, say, 20 pages. We’ve now downloaded 1,000 records of data, and if these are large objects, now I’m starting to worry about filling up the local store with too many objects. Does Ember Data automagically manage memory for me like this and will “throw away” older data and just request it from the server again if I need it? Or do I need to manually manage this somehow?
4. Being Careful with Foreign Key References
Say, I have the following models defined:
var User = DS.Model.extend({
username: DS.attr('string')
});
var Person = DS.Model.extend({
firstName: DS.attr('string'),
lastName: DS.attr('string'),
user: DS.belongsTo('user')
})
Now say I have a page that shows all users together with their first name and last name. I might do a query like:
this.store.find('person');
and in my Handlebars Template I might do something like:
{{#each person in controller}}
{{person.firstName}} - {{person.user.userName}}
{{/each}}
Am I correct in understanding that Ember-Data will blindly look for the right user_id when it encounters {{person.user.userName}}, which it will do by first checking the store, and if not found there doing one web service call for each instance of a user, which could be 50 separate web service calls for a row of 50 person records?
Basically, what I’m getting at is, what’s the best way to manage these foreign key relationships without incurring major network traffic? My thought right now is, per #1, to use a whole lot of database views, so that I get all the data I need from the web service in one fell swoop?
Summary
This is a long post, so thanks for reading this far. It’s been a blast working with Ember and Ember-Data so far and I really appreciate the helpfulness of this community.
Josh