We want to program, not configure. If we wanted to configure stuff, we would program Java.
traditional relational databases suck if you don&#x2019;t agree, you probably have not been using them enough
high performance and loose integrity (sides of the same coin)
django non-rel ORM exists also seems like a silly idea, http://www.allbuttonspressed.com/projects/django-nonrel I haven&#x2019;t looked into the current django-couchdb and other libraries yet, but it would be nice if these were ready for mainline use.
best approach to data migration: don&#x2019;t &#x2018;expando Models rule&#x2019;
Never having to migrate another database table again is a Good Thing.
Free hosting Standardized project layout (a Good Idea) Makes it 100x more likely that I&#x2019;ll build a throwaway webservice on GAE than I will with django.
django-fabric: http://theironlion.net/archive/django-fabric-deploy-your-django-apps-easily/ looks too complex, lots of configuration
Yeah, most of this stuff is not very hard to setup in one way or other. But having this stuff built-in matters. Programmers that don&#x2019;t understand that simple fact, ruin it for the rest.
It removes the necessity to think about it. You can just use the API.
free account will work for your toy website (which are super easy to get started) as soon as it gets serious you can just convert $ into scale, you never have to hire (or become!) a sysop to configure EC2 instances yourself
also you don&#x2019;t need to backup because it&#x2019;s a gridded setup, it will generally never go down (except when it does), at least it won&#x2019;t go down for the more mundane of reasons
no JOINs no aggregates no DISTINCT
http://en.wikipedia.org/wiki/Denormalization adding redundant data or by grouping data (remember, we don&#x2019;t have JOINs) for instance cannot query SELECT DISTINCT city FROM entries so either walk through all your records (bad idea!) or make a new table called Cities and only put city stuff in there
A bad idea if it happens, but because everything in App Engine is in the request/response paradigm, this can be difficult if you want to do some complicated stuff that is hard to decompose/incrementalize. But webservers aren&#x2019;t really the place (yet!) for that kinda stuff.
A Good Thing (you can use any templating language you want), but we&#x2019;re stuck on the old 0.96 version (which is frankly silly given the number of updates App Engine gets).
Would be nice to have.
It feels very oldschool if you remember CherryPy (that&#x2019;s what I used before Django came out).
Not that hard and pretty easy to write a website in.
can&#x2019;t really remove www. Domain linking in Google Applications is a fucking ghetto (even for domains you completely control). It&#x2019;s doable but it&#x2019;s very much harder than it should be.
It could be way prettier and nicer to use than it is. Common workflows could also be made easier.
This is pretty nice from an ops point of view.
Google is branding App Engine as an Enterprise product. All good software engineers know that the Enterprise is where programming goes to die. This may yield: - better availability (SLAs and that kinda crap) - more conservatism in development - a bigger focus on Java because of paying customers Which is a mixed bag.
Any system that removes configuration options and let&#x2019;s you focus on the programming part (on getting work done) is a good system.
App engine beats pony.key
My App Engine has
more horsepower than