Aral Balkan

When I was first starting out with Google App Engine (GAE), I wrote a short post detailing my thoughts on whether to use Django or Google's own webapp framework for GAE projects. In that post, I concluded that "there isn't a compelling reason to use Django at the moment with GAE".

Since then, I've re-evaluated my decision and, a few weeks ago, I ported the Singularity web app to Django from webapp.

Here are the main factors that contributed to my decision:

• I wanted to use features in the latest Django trunk (0.97+) and the Google App Engine SDK ships with 0.96. I also did not want to be tied in to updates from Google for the Django framework.
• Google released the Google App Engine Helper for Django which makes it very simple to set of a GAE Django app.
• And, finally, looking through the source of Rietveld, I saw that Guido van Rossum is using Django for his Google App Engine app. And heck, I think he knows a thing or two that I may not.

Going with Django means that you can take advantage of more existing functionality (Django middleware, etc.) and, should you want to move away from Google App Engine in the future, there will be less code to rewrite. (Though, realistically, if you're doing anything with data, you're pretty much tied in to the DataStore at the moment until there is a suitable, scalable alternative that you can port to without completely refactoring your data layer.)

So my new take on this is that it makes a lot of sense to build Google App Engine applications using Django instead of pure webapp.

To get started, check out the Google App Engine Helper for Django.

Comments

• Hi Tom, Thanks so much for reporting in -- happy to know I made the right decision! :) And thanks also for the session notes.

  by Aral on 2008-06-02 16:18:24

• Hi, I am currently in the middle of writing a book on Google App Engine, was at the Google I/O question, asked Guido in the Fireside chat about support for 3rd party components such as Django, and interpreted things in a different way. I think the webapp framework IS the best approach at this moment. The real beautify of Python web development is the WSGI standard. There are many wonderful things happening with WSGI and the webapp framework currently supports WSGI fully unlike the current trunk version of Django. If you want to use Django components then it might make more sense to use the current django templates and URL dispatch that come with the webapp framework. In reality, webapp is a forked version of Django with support for WSGI, due to the brilliant work of Ian Bicking: http://ianbicking.com.

  by Noah Gift on 2008-06-25 01:18:05

• Heh, I was next in line at the mike when Guido stopped taking questions! Ah well. I have some notes posted from App Engine-related sessions, although very raw notes, and not that particular session. Trying to get a handle on how to get all this set up correctly...

  by Charlie on 2008-06-04 03:15:09

• Hi Noah, I'd love to hear more about the book you're writing. If you need a tech reviewer, etc., give me a ping -- I'm interested! :) It is interesting the Guido is using Django himself for Rietveld.

  by Aral on 2008-07-01 17:26:14

• You made the right decision. I was at Google IO this week where Guido gave an hour long presentation about how to set up and utilize Django 0.97 on Google App Engine. In the Q&A that followed, I asked him if there was any reason to use the built-in webapp framework instead of Django, and he said that webapp was much simpler and easier to get started with, but that Django was much more powerful. In a later "Fireside Chat", he added that they will not be adding any more features to or actively developing the webapp framework. Given that, I think it's clear that the vast majority of App Engine development will happen with Django. I wrote up my notes from the App Engine sessions at Google IO here: http://offermann.us/2008/05/29/day-one-at-google-io/

  by Tom Offermann on 2008-05-30 21:47:52

• Well you got a point with trunk, there is no real reason to use 0.96 for new projects. The helper is indeed a very nice tool, although it still makes you learn django (if you haven't) As for Guido, we all know he has a think for django. One point against django that you forgot is that it's made as a monolithic component, so ones you start using parts of it things get nasty, for example take a look at how much trouble the appengine people had to go thru to be able to use django-templates in webapp. Just read the module docstring of google_appengine/google/appengine/ext/webapp/template.py That said I totally agree on the wsgi comment from Noah. In fact I can tell you that I'm using pylons on appengine, but the core is webapp and I don't have pylons installed on that virtualenv :)

  by jorge on 2008-07-29 04:50:58

• Django make a sense only if you are used this framework. But the real trouble is django is about 800 files (12 megabytes) and for GAE the number of files count. Also, apparently Django in GAE uses a extra amount of resources.

  by magallanes on 2009-10-19 20:00:15

• this is a bit of an old post to be commenting on, but still.. I'm a bit concerned about refactoring the data layer for my application as well, in case I chose to migrate to a non GAE platform. But the way I see it, having chosen GAE you have basically chosen a hierarchical key-value data store over a traditional SQL engine. Therefore I'm assuming that if you chose to port your application to using CouchDb, MongoDb, Dynamo, or Tokyo Cabinet (none of which I have used btw, BigTable being my cherry breaker away from usual SQL), it should not involve a massive rewrite. As opposed to say porting your app to using Postgres or Mysql. What are your thoughts on that? Have you used any of the other key value stores or ported apps between them? cheers

  by arun on 2009-10-21 12:23:07

• Doesn't the GAE not supporting straight Django models make running a local development version impossible? I'm assuming the GAE models won't work on sqlite for example. Unless I want to maintain two separate data layers. I'm trying to decide what host to use for a new Django project and would love to use the free GAE while its young, but this could be a deal breaker.

  by sean on 2010-04-16 04:36:28