in Projects, Programming, Technology

Google App Engine Evaluation

I spent about 4 or 5 days re-implementing one of my projects on Google App Engine. A basic version of the app is now live, but I’m waiting for the DNS to go through, so I won’t link to it just yet. Overall, I love it. This was my first exposure to Python and Django too – and I really like them.

Some quick pros and cons:

+ Python is really learn-able. I found it to be a easier learning curve than Ruby. Although, Ruby’s elegance will probably still win in the long term.

+ Local development server for App Engine is good. Behaves pretty much the same as the real thing.

+ Deployment easy (still need to figure out how best to do automated testing for Django/Python)

– Bulk load slow both locally and live. Only gripe is the speed of the local simulated datastore (I think it is file system based).

– Had some trouble with Python paths. Just beginner issues.

– Tried both XCode, TextMate, and Aptana (with Pydev) IDEs. Aptana wins because it requires less clicks to get to your file, and also has Javascript and HTML formatting. Pydev auto-complete is so-so, don’t know why you can’t navigate to a library method (maybe I don’t know the hot-key?)

Bulk upload samples from Google were good learning material, but it probably would have been more time effective to just upload data by doing HTTP Posts to my app.

– No support for bulk delete. Work around is to write a page that deletes as many rows as it can without hitting your CPU/page response time quotas. Even better work around is to modify the “limit” parameter in the query string in the web based data editor so you can manually delete a couple hundred entity rows at a time.

– Not clear what the steps should be for performing a schema change. If you make one to your models, code just runs until you try and load data that doesn’t fit the new types. No way to transform existing rows without loading them all up into a page and saving them. This is going to make future revisions of an app difficult.

– Apparently no option for enforcing referential integrity (understandable given the goal of scale)

The restrictions on GQL and the App Engine data store count as both a benefit and a limitation. Even in my simple app, I was forced to denormalize and add more columns than I would’ve liked to satisfy the requirement for an index to match every query. My app is mostly read-only right now, adding more write logic will require updating these denormalized columns. As I gain more experience, and GQL gets richer, I don’t think this will be a problem compared with the huge scaling benefit. The App Engine “sandbox” just forces you to do your optimization work up front.

So what kind of apps will work well on App Engine?

Given its infancy, it is hard to see very data-intensive apps working on App Engine. It does look like the perfect environment for hosting mashups and Facebook/OpenSocial apps. Also, I expect a thriving ecosystem of simple open source App Engine components (a blog, a wiki, etc.) that can stiched together.

Write a Comment



  1. Adam Loving’s Blog » Blog Archive » What next for Lookmarks?

    […] of all those unexpected “customers”. I’ve got the site half-way ported to Google App Engine, and I’m taking an internet marketing course (I’m ashamed to admit) that I’m sure […]