31. • Work within the bounds
• Use indexes
• Use memcache
• Create JSON endpoints
• Compose complexity at the client side
Editor's Notes
My extremely biased take on why App Engine is more suitable for a variety of needs than django is currently.
I have programmed Django for ages somewhere after launch in 2005. Before that I was using CherryPy (more on that later). This is going to be my extremely biased talk.
http://www.cherrypy.org/
Recently I have been doing some stuff in Google App Engine and I’m quite enamoured by it. It was mostly unusable on first launch but it too has come a long way in short time.
different strokes for different folks
Fun if you want to write another blog (!) or other content heavy editorial site.
Or huge complex websites that compose multiple apps.
Coming from a newspaper background, this is rather duh!
Scalability is not the same thing as performance. It means that as your application gets bigger, it does not degenerate (like Twitter does).
And for complex small, data heavy sites.
App Engine has some distinct characteristics which are cool (and some which aren’t).
You can, I’m not sure why you would. Without most of the features that make django worthwhile this seems like a pretty silly proposition.
While app engine itself is perfectly usable for a variety of applications.
Experience trumps programming, programming trumps configuration.
We want to program, not configure. If we wanted to configure stuff, we would program Java.
traditional relational databases suck
if you don’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’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’t
‘expando Models rule’
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’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’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’t need to backup because it’s a gridded setup, it will generally never go down (except when it does), at least it won’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’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’t really the place (yet!) for that kinda stuff.
A Good Thing (you can use any templating language you want), but we’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’s what I used before Django came out).
Not that hard and pretty easy to write a website in.
can’t really remove www.
Domain linking in Google Applications is a fucking ghetto (even for domains you completely control).
It’s doable but it’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’s you focus on the programming part (on getting work done) is a good system.
