10x More Productive Blog!

I was quite excited to hear about Google's hosted application platform. I grew somewhat tired of my home project setup, which is PHP/MySQL located at a shared host. The Google App Engine seems like an ideal environment for me to do some educational hacking, without having to bother with the software and hardware infrastructure, great!

Although I've been looking at Python for a number of years, I've never completed a serious project with it. I'd be probably more ready to work with Ruby or even Java. Still, Python does seem to be the right language for the platform. It's a modern, dynamic language and has an established, extensive set of class libraries for nearly every need. Though only Python-native libraries can be used on the App Engine, there are still thousands of readily available modules to work with.

It's interesting how Google customized Python 2.5 for the App Engine to keep it safe and control its resource impact. Threading, spawning sub-processes is disabled, there's no socket or file access, and each process must terminate within a time limit, otherwise it is shut down. These limitations make sense, they need to keep shared hosting viable. By locking down potentially troublesome areas, it's not up to the individual developers to manage the resource consumption in check, it's the safest route. On the other hand, it'll be interesting to see how seriously this will impact the development of a relatively complex application.

Although developers can work with a number of native Python Web frameworks, I've decided to work with the built-in frameworks, to minimize the hassle of configuring and debugging stuff. It took me about an hour to get the SDK, install it, and watch the demonstation video. This is what I've achieved in about 4-5 hours of hacking afterwards:

1. Setting up URL Handling

I've structured my web application into three separate sites, under three URLs, one area for public access, one back-end site for authoring, and one administrative website. I needed to configure the web application to handle these separately.

There are two discrete layers where URLs are handled. The initial configuration is managed in the app.yaml application configuration file, like this:

- url: /index\.html
script: home.py

This maps specific URL patterns to the Python scripts that will handle them, and configures authentication as well. It's fantastic just to declare the login attribute, and get the whole login, logout, registration process from Google Accounts.

Developers are able to fully configure URL handling in the yaml file, however it makes sense to dispatch the individual Actions users can do on the specific area of the site through the provided Python WSGI framework. After the request is routed based on the URL pattern, the Python script where the request was routed to is able to process the request further, and instantiate specific classes for specific operations.

In this example, the /author URL pattern is mapped to author.py, and within the author.py file, the actions are dispatched to individual classes (which can be implemented in external modules, or within the main .py file).

2. Displaying content, templates

Once the requests are dispatched to classes, the post or get functions are called on the class, depending on the type of HTTP request. Not surprisingly the function will have access to all the request variables, and will be able to output the response through a simple self.response.out.write() function. Any reasonable complex web application will probably need more than that. Instead of developing yet another web templating application, Google decided to bundle the (quite decent) templating module from the Django framework.

Basically you can set the dynamic data into variables, and pass them into a HTML template through this framework. Within the template, lists can be iterated, there are conditional expressions available, and you can even invoke functions.

It's not a tag-based template engine, but it's quite easy to read and author.

3. Working with the datastore

One unique aspect of the Google App Engine is that Google's BigTable platform is provided for persistent storage. This is extremely cool as us developers get the same highly scalable, high-performance data store that many Google Apps use. It is however not a traditional relational database, so I had to read up on it for a while to figure out how to use the API. It is not difficult at all to quickly create Model classes, add various attributes, use the GQL query language to do selects, and create new persistent items through simple put() methods. I'll however need to spend some more time to understand how to handle relationships by adding ReferenceProperty type attributes to the model classes.

Overall I don't think I'll have problems with the Datastore API, but so far this API had the biggest learning curve for me.

4. Deployment, hosting

I already had a registered domain for the project I plan to implement on the Google App Engine platform. It took a little while to find the proper docs about how to set it up:

• I had to register the domain within Google Apps for Domains
• Then once the domain is registered for Google Apps, I needed to configure a verification CNAME within GoDaddy's TDC management tool.
• Once the domain works within Google Apps, the App Engine application can be configured to work with the domain through the Console, in the Administration/Version section.
• The wizard that leads through the process of configuring the domain has one problem - it does not display the additional step required to configure the "A name" for the domain. Luckily I've found the FAQ for this.

So I now have a few working pages, querying and persisting data into the Google Datastore, configured for the proper domain. It's been a blast to work with this. The local development environment is great (which I use with TextMate as an IDE), the documentation and the examples are a decent starting point, and it's very easy to deploy the code onto the hosted environment. I'll try to finish this application in the next few weeks, and will report on my progress through this blog.