URL routing in Python web apps

There are two places to put URL routing information. The first is in your app.yaml, in the 'handlers' section. The second is in the python script that is called *from* the handlers section, at the end, where you create the webapp.WSGIApplication.

"So," you might think, "all I have to do is split my application into modules, assign modules to urls in app.yaml, and then assign sub-urls to classes when I create the webapp.WSGIApplication, right?" Wrong.

Say you are creating a backend for a Flex rich client application, and suppose you have something like this in your app.yaml:

handlers:
- url: /flex
  script: client.py

and then in your client.py:

application = webapp.WSGIApplication(
    [('/test', TestPage)],
    debug=True )

If you think that this will cause the TestPage class to be invoked for a URL like "http://localhost:8080/flex/test" then you are unfortunately wrong. Perhaps because Google's Getting Started documentation deals with pages that are available directly off the root, I naively thought that the url filters in the webapp.WSGIApplication got *added* to the end of those in app.yaml, so that you could use app.yaml for first-order routing, webapp.WSGIApplication for second order routing.

But no, the url mappings in webapp.WSGIApplication have to match the *full* url. App.yaml just points to the script that needs to do the work: the url fragment that it matches is not then stripped from the start of the url that's passed to the script.

So if I want to handle "http://localhost:8080/flex/test" in a TestPage class in client.py, I need to have something like:

handlers:
- url: /flex/.*
  script: client.py

in app.yaml and:

application = webapp.WSGIApplication(
    [('/flex/test', TestPage)],
    debug=True )

in client.py.

Why is this important? It's important because it means that your WSGIApplication scripts need to know how you are dividing up your url space, which I consider bad form. I can't, for example, change the base url for the data endpoints for my rich internet applications from "/flex" to "/ria" just by changing one line in app.yaml, which is what I would very much like to do. Instead I have to hunt through all my WSGIApplication scripts and change every single mapping in them as well.

Google App Engine, now with added caffeine!

So I'm coding away my baby steps in Python, feeling all proud because I've got about 80% (ha!) of the site that I'm using as a test project converted over, when I open a new tab to look once again at the syntax for the templating language and BAM! I see "Java Early Look" on the left hand of the page.

Seriously? Java? They actually did it? Trembly-hands time, but I managed to click to this post on the Google App Engine Blog before the excitement got to me and I had to make a cup of tea.

But there's even more, including long awaited support for cron jobs, a Secure Data Connector so that App Engine applications can access data from behind your firewall, and a new version of GWT that can work with the Java version of App Engine as a back end. Empires will surely rise and fall due to this release; I wonder when they'll be adding support for .net? (Answer: Never!)

Secure Data Connectors look particularly interesting. It all depends of how fast it works of course, but I can see how it might enable mash-ups between relational data held on your own private servers and big-table data held in the app engine data store. I had been wondering if Google were going to address the fact that Microsoft is including SQL Server support in Azure (though we have yet to see how well that scales in practice), and this provides at least a partial answer.

There's also intriguing talk in the blog post of something they call Database Import: "move GBs of data easily into your App Engine app. Matching export capabilities are coming soon, hopefully within a month." Unfortunately the link they give points to the old how-to page on uploading data from CSV files. Maybe they'll fix the link, or maybe that page will get updated soon.

What is this blog, and why am I writing it?

I've just started seriously porting a Java/Postgres-based website to App Engine, and already I'm finding problems with holes in the documentation, misleading threads on discussion groups and so on.

The documentation Google are currently supplying with App Engine is excellent for those first baby steps, but seems to fall down as soon as you enter the real world. No doubt that will be rectified in time, but until then you're left with scanning the source code.

The App Engine newsgroup, while a necessary resource for anyone doing App Engine based development, has quite a high signal to noise ratio. There are a lot more questions there than answers.

There are some good App Engine-related blogs out there, some of them written by very skilled developers, but they seem to concentrate on either topics of personal interest or problems they are running into at work. That is, they don't seem general enough. Sometimes, they aren't *basic* enough :)))

So I want this blog to be a resource for would-be App Engineers: intelligent developers who are new(ish) to App Engine. Because you can be extremely experienced in Java say, and SQL databases, but still be tripping over yourself when it comes to App Engine basics. The sort of thing you need when you are beginning.

I was originally going to call this blog "App Engineering", which sounds either more objective or more collegiate, or both. But appengineering.blogspot.com was gone (it redirects somewhere), so "App Engineer" it is, even though that might sound a bit me-me-me. I promise to try to make it us-us-us.