Google App Engine (GAE) supports both its own framework, called webapp, and Django.
So, which one do you use?
As far as I can see, there isn't a compelling reason to use Django at the moment with GAE. I just can't see what benefits it offers over webapp and you have to hack Django to get it to work. In all honesty, it looks like Google was very influenced by Django and if you already know or work with Django, working with webapp is a piece of cake. All the concepts transfer over. Heck, it even supports Django templates. (I'm so glad I started playing with Django a couple of weeks back, it has made working with webapp and GAE and walk in the park!)
One of the main differences is that it doesn't support Django's (excellent) ORM. This isn't surprising, though, since Bigtable isn't a relational database and Google's own Datastore API is excellent. And you don't have to learn GQL. If you like the Django way of doing things with Model objects, you can keep working that way with the Datastore API. (Less importantly for state-maintaining Flash applications, but still crucially important for HTML-based apps, Django sessions are also not supported.)
It should be a huge vote of confidence and mind-share boost for the already-popular Django that Google's webapp framework is so similar to it. Google's support for Django is a clever move if for political reasons alone: instead of competing with (or, *shudder*, appearing to have forked) a popular open source framework, they appear inspired by and in full support of it. I can only assume that in time Google will add more Django features/support to webapp while continuing to support Django.
For my purposes, which include using PyAMF, Flash, and Flex with GAE, using webapp makes more sense to me at the moment. I've already outlined how I see Flash and Flex applications working on GAE in my previous post and it's cool to see that the PyAMF team agrees:
We need an approach that is closer to how PyAMF is implemented for Django, where we use the Google webapp WSGIApplication and map a gateway URL to PyAMF.
(Looking forward to the upcoming PyAMF 0.3 release with GAE support, Thijs -- exciting times!)
For more general reading on GAE, foobar has a thoughtful review of GAE advantages and possible disadvantages.
The Google App Engine: To Django or to webapp? article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.
Just had this same discussion with myself but actually came down on the other side - the main reason being portability. By this I mean both portability of skills as well as the final application.
Building something with webapp means it’s stuck with Google, on a platform for which they have yet to release the pricing for. Building something using Django means I have more choice. It’s not truly portable yet but changes would likely be relatively simple replacement affairs mainly in the models.
Having said all that, I am having to fight against Django to make it work at the moment so whether it’s worth the extra effort time will tell.
Hey Gareth,
I’ve been considering the portability issue and I hear you on Django being more portable in the here and now. It’s also true that the webapp framework is proprietary. Google have, however, open sourced it and they have released the Development Web Server as open source also. This is really all anyone needs to create webapp-compatible hosting packages that are not tied to Google. In the coming days, I am confident we will see other implementations of GAE that make it easier to move your app off of Google’s domain if you should desire.
So I don’t really see GAE/webapp as lock-in but rather as an emerging new de-facto standard.
“datastore API is EXCELLENT”?!?!?
Have you actually read the restrictions the datastore API has? Am I the only developer that thinks these are HIGHLY prohibitive. In fact it makes GAE largely unusable for me.
No way to pull something from a DB like “everyone who is over 23 yeas old, with blue eyes”?!?!? how do you not support that??? No way to query “everyone who is not from california”?!?! how do you not support that??? Only able to pull 1000 records max, are you joking me??
Am I missing something??? http://code.google.com/appengine/docs/datastore/queriesandindexes.html (see the “Restictions” section to be blown away)
Then, don’t use it
Well, I am just wondering if I am missing something here. I havent heard too many comments from Dev’s other than “this stuff is great” and “this is game changing”. All I can think is that they haven’t actually tried to write an app yet, which would be sad to start developing an app for a client only to have to tell them, “oh we can’t do that” very simple query.
The only other thing I can think of is that I am simply misreading the limitations and there must be another way to deal with the issue.
Hi Anthony,
Unless I misunderstand what you’re trying to do, you should be able to use filters to do that.
You will have to change the way you do things to suit how Bigtable works, however. Since disk space is essentially free these days, you should try and precompute as much as possible at write-time to minimize the cost of reads. And forget about normalization and joins (from what I’ve read, Bigtable does support joins but this hasn’t — yet? — been exposed in Google App Engine):)
OK so maybe I just dont understand BigTable all to well. I just saw in their examples (at the link above) that the following would error:
SELECT * FROM Person WHERE birth_year >= :min_year AND height >= :min_height
It also said that “Inequality Filters Are Allowed On One Property Only”, so you cant put a filter on birth_year and height if I am understanding correctly. Is there some sort of another way to get at this recordset? Do they offer subfilters of filters or something?
It also says that “The datastore does not have support for the not-equal (!=) operator for filters.” Which means I could not pull from the DB all records of people NOT from california. Unless there is some other way to get at this recordset.
I sure hope I am wrong here and there is some way to do this stuff because I cant think of an application I’ve written that didnt have need to filter on multiple fields at some point.
OK I am utterly confused now. Upon further review of the link I pasted above there is a section called “introducing indexes” which has as a sample the following query:
SELECT * FROM Person WHERE last_name = “Smith” AND height < 72 ORDER BY height DESC
That query looks strangely familiar to the one in the that they said was not valid in the “Restrictions on queries” section. It said “A query may only use inequality filters (<, =, and >) on one property across all of its filters.”
So, would someone smarter than me please visit this link and make sense of this page? It appears from the examples that it works the way you think it would, then they throw in this restrictions section which seems to contradict everything they have just said… help!
http://code.google.com/appengine/docs/datastore/queriesandindexes.html
TOO easy.
You can do things like, “select …. height>70 AND height<90″ the documentation says you can only use more then one on one property, eg height.
BUT you cannot use on more than one property in the same query.
for example “select … height>70 AND weight>50″ because now you are doing 2 properties height and weight.
LASTLY, you can use = for everything else.
eg “Select …. height=70 AND weight=70 AND sex=”male” AND birthday > 1977″ is valid because only 1 greater than query has been used.
If you think this is limiting, I would doubt it. Google uses this DB for nearly everything so if they can so can you. If it does become a problem you may have to preprocess some data or think of some smart ways to handle the data.
Man cannot wait for invite. Have built one app, nearly on to my next. I am so impatient that I have installed Django mod_python and sqlite on my server because I have been enjoying python a lot (but Django seems very complicated when compared with GAE).
Cheers, John.
webapp is strikingly similar to webpy (even its name is similar) and, as far as I know, its developers were also very influenced by webpy.
And webpy works with GAE right our of the box without any modification.
Actually, webpy requires even less typing than webapp, which seems to be more explicit. But the most important thing is “portability”.
Only the database api changes (because of bigtable’s datastore), but all the rest can be kept unchanged.
So if you want a very simple solution (even simpler than webapp) and you want portability, give webpy a shot. You will like it.