Model and Primary key setup for Django Rest Framework Ember Adapter

Design
1

Hi,

I am using Django Rest Framework Ember Data adapter. I have a user model for which I want to use “username” as its key. For example, I have:

// models/user.js:
export default DS.Model.extend({
    username: DS.attr(),
    first_name: DS.attr(),
    last_name: DS.attr(),
    email: DS.attr(),
    is_active: DS.attr('boolean', { readOnly: true })
});

and

// serializers/user.js
export default DS.DjangoRESTSerializer.extend({
  primaryKey: 'username'
});

Problem is, after I modify primaryKey as above, the {{id}} field in templates start showing the username, and {{username}} becomes empty.

Also I saw this in the DRF adapter code in updateRecord:

var id = get(record, 'id'); //todo find pk (not always id)

I guess primary key support is not there yet, and I should address the user model with its numeric ID not to confuse things.

The other problem I had is that I had to use readOnly on one of the fields as below, to generate a PATCH request instead of PUT:

is_active: DS.attr('boolean', { readOnly: true })

This triggers a PATCH request which DRF accepts as OK. Otherwise for a user model partial update adapter generates a PUT, which gets rejected.

Finally in DRF adapter there seems to be Async belongsTo/hasMany issue but issue seems to be closed. Is it still pending, or what is a good workaround? https://github.com/toranb/ember-data-django-rest-adapter/pull/63

Thanks, Bahadir

2

I did a few projects in Django a few months ago and on the last one I tried to use ember-js with ember-data. I found that the adapters and serializers that were available on github etc. really weren’t up to snuff compared to their rails equivalent. Ultimately I did fall on the DRF adapter, but I crafted any complicated responses by hand using DRF’s response() method.

It’s a real shame that Django can’t be used out of the box like rails can. I love Django to death, I actually prefer it to rails (nobody shoot me please), but ember just isn’t quite mature enough in that it can comply out-of-the-box with multiple frameworks.

I started working on a client side adapter for DRF a few months back, but ultimately didn’t have the time to finish it. I’ll take a look at the code and see if I can find a quick solution to your problem. But yea, their probably isn’t anything out of the box to solve your problem and if you really need to rig something write your own serializer server side to conform to ember-data or use the response() method in your view to write it directly:

from DRF import wherever_the_response_method_is

def userView(request):
    return response({"user":{"id":1, "name"Benjamin", "favorite_web_framework":  "Django", "comments": [1, 2, 3]}})

etc.

3

I am full time on a large scale Django/DRF/Ember application. We have been using Toran’s ember-adapter but as mentioned things do not work as expected so lots of work arounds are in order. I’m happy to chat privately and share methods for dealing with various issues. In particular, I can show you how I deal with async relationships - which is not pretty but seems to work well enough.

At this stage, I am waiting for DRF 3 to come out. At that point, I will be looking to build an adapter for DRF that allows DRF to generate perfect a perfect Ember Data style API so that it will be possible to use pure ember-data out of the box with DRF. I think this is the best approach (as opposed to using an ember-data drf adapter as I currently am) for a few reasons:

  1. Depending on how your data is structured, lack of sideloading can greatly increase your API response sizes.
  2. DRF developemnt is more stable and predictable than ember-data. So it will be easier to maintain an add on for DRF than to maintain an add on for Ember-Data which is constantly getting bugfixes and redesigns.
  3. Adding front-end dependencies increases your app size and increases processing overhead on client side (admittedly this is probably negligible)

Anyway happy to discuss any of the above and share code examples. Unfortunately I think we cannot really make progress until we at least have DRF 3 and (ideally) Ember-Data 1.0.

4

For anyone who stumbles across this, I have started on a plugin for DRF that supports Ember-Data by adapting the server side response. The github is here.

Very interested in any feedback others have on this.

1 Like