Hands on with Google App Engine

ScreenshotEarlier this month, Google launched their App Engine cloud computing platform. The initial beta slots filled up very quickly, but over the weekend my number finally came up and I was able to start working with the product. (Even if you’re not in the beta, you can download the SDK and work with it on your own computer). After some hands-on time, it seems to me that App Engine will indeed be useful to many web developers – though I continue to think it’s not really a direct competitor for Amazon’s more flexible AWS platform.

The process of developing an application for App Engine is quite straightforward. You write your code on your own computer using Python (the only choice currently; there’s a decent tutorial on the main Python web site if you need it). To test the application, you run a local development web server that emulates the App Engine API for you. When you’re satisfied, another Python script prompts for your Google login information and then uploads to the server for you. You can pick your own URL, using a subdomain of appspot.com or your own Google Apps domain.After your application is uploaded, it’s available at your URL with, as far as I can tell, no delay at all. App Engine’s dashboard lets you manage versions of the application, review log files, and track the use of the metered resources that are allocated to you.

You don’t have unrestricted access to the host where your application is running; rather, it’s sandboxed to keep you from doing bad things. The sandbox restrictions are not terribly onerous; you can’t use the file system or the network, or spawn a sub-process. On the other hand, you do get access to several App Engine-specific APIs:

  • The Datastore API provides an object-oriented database with its own pseudo-SQL language.
  • The Users API gives you trivially simple integration with Google Accounts.
  • The URL Fetch API lets you grab data from other hosts, using port 80 or port 443.
  • The Mail API lets you send email from your application.

And, of course, you have access to frameworks already built in Python – notably Django, a version of which is included in the SDK. This will give current Python web developers a leg up in building things with Google App Engine (Google has promised support for additional languages, but there’s no timeframe on that).

Even if you’re not currently a Django hacker, though, there are opportunities here. The URL Fetch API makes it easy to create mashups using data from other services that provide a RESTful API, which is increasingly common in this Web 2.0 era. And it’s super easy – a matter of 3 lines in a configuration file – to serve static files from an App Engine application. That means that, depending on where they draw the line for free versus paid use after launch, you can use App Engine as an asset server for other web applications. Apart from the free storage, this gets you caching across Google’s worldwide infrastructure.

The cost you pay for this functionality is good old-fashioned vendor lock-in. Although they’re written in Python, it’s unlikely that any non-trivial application built for App Engine will run anywhere besides the Google servers for quite some time to come. Provided you’re willing to put your eggs in the Google basket, though, App Engine provides an easy way to get scalability with near-zero effort.


Comments have been disabled for this post