Guido van Rossum (Google)
Best practices for using AppEngine with Django. Appengine does one thing well: runs webapps. It only handles HTTP requests: think of it as an RPC server. Resources are scaled automatically - requests may go to the same process, serially, or different processes, in parallel or serially. There is a highly scable datastore based on BigTable - not SQL, there are no joins.
An application is a directory and everything underneath it (symlinks are followed!). Application metadata is in a app.yaml file, which maps URL patterns to request handlers, and seperates static files from program files. The SDK emulates the deployment environment.
Request handlers are invoked like CGI scripts. Environment variables give request parameters, and response is written to stdout. CGI is not slow (in this case)! Modules remain loaded, and main() is called for each request. Can use module globals for caching. CGI doesn't mean clumsy! WSGI support is layered on top of CGI.
Some talk now about app engine project setup, although I prefer the google-app-engine-django project boilerplate. One interesting point is that Django 0.96.1 is preloaded, which is pretty old, and that there are some slight differences between local and deployment.
One interesting point about main.py is that here you can arrange to have your version of Django loaded, to replace the old 0.96.1 version bundled in. Also, in settings.py you can set DEBUG to true when os.environ['SERVER_SOFTWARE'].startsWith('Dev').
Aha! He recommends google-app-engine-django too! :o)
Unit tests: you have two options. DocTests or unittests. DocTests are string literals which define a sequence of console command - result conditions. Unittests are modelled on JUnit. You can created fixtures to be loaded into the datastore also.
Wednesday, 28 May 2008
Rapid Development with Python, Django and Google App Engine
Subscribe to:
Post Comments (Atom)
RSS Feed
0 comments:
Post a Comment