Creating a basic ember.js + django app


I’ve primarily worked with the Django backend and now want to use ember.js to build the client side presentation. I’ve read @toranb’s replies on the thread Deploying ember with django. I’ve also had a look at ember-django-grunt. However this is more complex that I need for now. Going by the questions asked in the thread, here are my responses

1.) can you leverage something like node.js / npm to build the assets with grunt or do you need something in pure python?

I am not familiar with npm and grunt. I installed them and followed instructions in ember-django-grunt and read up a bit so I think I understand why someone would want to optimise certain tasks, but I’d prefer learning to do without these if possible. I’d rather understand one new thing (ember.js) and get it to integrate with my backend than try mucking about with multiple new things and not understand anything.

2.) what version of django can you use for this project?

Currently on 1.6 and plan to move to 1.7 as soon as it is released.

3.) assuming the answer to #2 is 1.3 / 1.4 / 1.5 -what REST api framework will you layer on top of core django? do you have a preference? I think the major 2 in the wild are /django-rest-framework and tastypie

I’ve picked django-rest-framework

4.) do you want to start out with vanilla models or would you need a full blow object store for the javascript application (something like ember-data or ember-model) ?

I am planning to start with simple django ORM models.

here is my generic answer w/out knowing any of the above.

First I would scaffold your django models like you would in any django app. Next I would pip install the django-rest-framework (my REST api of choice). Then I would learn grunt to build a client side build step that could compile your handlebars templates (using npm) Finally I would write a really simple ember app that uses a single model from the REST api (running grunt locally to see it all work).

I guess I am not sure about the grunt step… This is most likely coz I am a noob. Do you think I should take a closer look at it if it is going to be that important? In any case I’d like to know how to manage without that if it’s at all possible (and makes sense)


To your point about grunt/npm/putting the cart before the horse

If you can avoid/skip/ignore the handlebars pre-compilation step you don’t need grunt/npm or ember-django-grunt. Just inline your handlebars templates (in your index.html that gets sent to the client using a script tag like the below).

<script type="text/x-handlebars" data-template-name="application">
<div>footer goes here or something globally shown</div>

<script type="text/x-handlebars" data-template-name="foo">
<h1>html code goes here</h1>

Over time you will find this doesn’t scale (and you get a perf improvement when you precompile these templates w/ grunt or broccoli)

This would make for a great “how does this all work” step -from here you can add ember-django-grunt or a traditional grunt build yourself :slight_smile:

Great :slight_smile: So all I really need are - ember dependencies, django-rest-framework & the std django stuff. Cool. I suppose that means I should be able to get the project working on windows as well for now? Any recommendations as to directory structure with multiple django apps in the project? Any common gotchas?

I know for a fact that people have used the django adapter + ember + grunt on windows so this should be good either way (before w/ templates inline and after if you need grunt later on in the project).

The only “future” item worth looking at would be the ES6 module transpiler + grunt (not sure of the windows experience for this just yet).

I have two cases here where I’m using django + adapter + ember + grunt on OSX everything inside a static folder, using handlebars inside the views.

For another project we have decided to split in two repos so wen can leave the web app separated from the backend. I found this last approach much better since you can use ember-cli, broccoli is way faster than grunt plus if we need change the backend we wouldn’t have any extra work at all.

@toranb - That’s good to know. Means I am set for now.

@henriquea - Hmmm… The second approach seems interesting… so u r saying that the client side web app is stand alone with no backend and consumes data from another app that just exposes data via api? Similar to accessing google charting api? This might b a better way to structure things… Will also make things simpler inside my head as to what logic should belong to what… Will explore this…

@mithrilstar the first is useful when you don’t want to go with a single page app. In my case I have a pretty admin built on top of Django. The project has many views and I’m using Ember Components in a few parts of the project.

For the second, yes. The client-side is standalone using the default structure that Ember-CLI generates for you. Then I’m using Django as REST api.

App.ApplicationAdapter = DS.DjangoTastypieAdapter.extend({
  serverDomain: '',
  namespace: 'api/v1'

App.ApplicationSerializer = DS.DjangoTastypieSerializer.extend({});

This approach is turning out to be the best option so far, you don’t need to have the backend plugged to work. Also in terms of costs you can manage better the load balancing between both. The client-side is on S3 and the backend on EC2.

I also like the second approach. Ember CLI is a great project that helps you to keep an overview over your scaling app and makes it unnecessary to keep all templates in Our main HTML file.

@henriquea Are these two repositories available for the public? I tried this approach but I had some struggles due to the csrf protection built-in in Django. How have you handled the problem of getting the csrf_toke ? I do not want to deactivate the csrf protection for every single .

Sorry for reviving this post but as it still pops up on the first result page when searching for django and ember on google, I thought it was worth it.

In the spirit of the second approach, you can check out the cc_django_ember_app from . It will set everything up for you, including authentication