Playing around with Google App Engine

I’ve gotten a chance to play with the technology a bit in the last few weeks and have a few things to say about it. My first response towards it was pretty ‘whatever.’  There was the fact that the last over-hyped Google for developers launch (GWT) isn’t really all that.  Automatically scalable web apps are pretty neat, but there are already a bunch of grid offerings available.  MediaTemple, EngineYard, and Amazon’s EC2 are all variations on this theme.  Compared to these production services, Google’s offering is a little weak.  First, like all Google products, it’s Beta.  Only 10,000 invites are available.  You can only have 500MB of storage.  You can’t upload a file larger than 1MB (found this out the hard way while building Apptunes).  You can’t launch a background process.  You can’t take too long to service a request.  And so on.  Of course, it’s a free private beta, so all the whining is only slightly applicable.  The end result was, we built support for it, built a demo, then I forgot about it and moved on to other things. Until I few moments to mess around at work.  Our demo didn’t make much use of Google’s model support.  Nor did I have to write a lot of Python.  So I set out to build a more complex demo application that would let me play around with the persistent storage engine.  It wasn’t before long before the App Engine (and python) really started growing on me. A major benefit to using Appcelerator is all the service backends are structured similarly.  So although I’m a Rails and Java person, I didn’t have to think too hard about where to put things in my App Engine project.  Instead I could focus on learning Python.  The good I found about Python:

• It’s a stickler for spacing.  I like this since when I was a TA I had to look at a ton of indecipherable code.
• I don’t have to write a lot of punctuation or litter ‘end’ everywhere
• The ternary operator is there, but a little weird (return1 if <condition> else return2
• Munging arrays is syntactically very sweet: notes = [{'note': note.text} for note in query]

Once I figured the syntax out (with a lot of help from the Atlhack’ers) I was able to marvel how cool the datastore is. The neatest feature of the datastore, is that it’s a datastore, and not a database.  There aren’t any tables to define and worry about.  This forces you to think of your data in a different context.  It’s a lot more like a datawarehouse, where the pertinent question is: How do I want to access my data?  At first, I tried to treat my models like I would with Hibernate.  Then I read a post on the google group stating that “normalization doesn’t scale.” Which brings me to another downside.  I couldn’t figure out a way to cleanly migrate or delete all existing data.  The above epiphany didn’t occur until after I pushed version 1.0. Since it’s not a relational database, queries work differently too.  Any query you define does not get executed until you actually try and use the data.  Which means you can build a query then attach filters all the way up to the point where you access the first element.  Syntactically, it’s not very different from ActiveRecord or HIbernate, but I found the concept very cool. Finally, there’s the undocumented, somewhat unfinished feature of automatic full-text search.  If you want check out what I did live, take a look at Yesnotes.  You’ll need a google id to log in. After working with it for a bit, I realized a few things.  First, I spent almost the entire time focusing on my code, not on what database to run, or how the production environment should work.  Second, the whole thing makes a lot of sense (especially when tied to an ajax framework like Appcelerator). I think Google hit the mark on this one.  If you just want to build something, App Engine is a great way to go.  There’s all sorts of small (and not so small) useful apps you could build very quickly with App Engine.  Not to sound too fanboy, but I’m really looking forward to the official launch.