Google App Engine from a PHP developer’s perspective
When Google AppEngine was announced, a lot of sturm und drang went through the PHP community because it only supported Python. Of course, the same thing went through the Ruby community. The Perl community, not so much, because they’re used to getting ignored.
Anyway, I didn’t really give a crap, because Python is a cool language, and I’ve been interested in learning new languages and frameworks lately. PHP is cool and all, but having done it for 9 years, you kinda look for new challenges. Plus, getting hung up on one language is a sure way to be a boring dude who gets caught up in lame religious language wars.
I’ve actually toyed a little with Python here and there, but never dove in on a significant project. I’m someone who really likes whitespace and indenting rules and such, so those aspects of the language never bothered me. Otherwise, Python is a good fit for me philosophy-wise, because it’s totally the anti-Perl, lacking goofy magic characters and 1000 ways of doing the same thing. I can’t stand languages where “~^s” means “find all numbers that start with the letter ‘s’, add them, multiply them by 75, and then post the result to Twitter”. I’m not freakin’ R2D2 here.
So anyway, I started working on a little side project with Alex Payne on GAE. It’s been an enjoyable experience to work with a new language and framework, and there’s a lot to like about what GAE offers. It also has some rough edges, though, in some areas you’d be surprised by.
The good
The webapp framework
The built-in framework for handling requests is webapp, a nicely straightforward system for mapping requests to handlers.
class MainPage(webapp.RequestHandler):
def get(self):
self.response.out.write('Sup dogg?')
class FooPage(webapp.RequestHandler)
def get(self):
self.response.out.write('This is the foo page')
def main():
wapp = webapp.WSGIApplication([
('/', MainPage),
('/foo', FooPage)
],
debug=True)
wsgiref.handlers.CGIHandler().run(wapp)
So we define a class to handle a specific URL request, and define methods for GET or POST or whatever HTTP commands inside those classes. Then in the main function we map URLs to those handler classes in the webapp.WSGIApplication constructor, and then start it up.
I like this because it’s simple and easy to follow. I could read the code before I’d written any myself and get what’s going on. There’s no magic happening here; no auth-mapped stuff or relationships established because I happened to name something the right way and put it in the right directory. Convention is good, and we have conventions here, but the conventions are clear and obvious.
Django templating
Django has a really nice templating system. GAE lets you use it outside of the whole Django stack. This is cool. For example:
# define some values to plug into the template
tpl_data = {
'page_title':"This is an awesome page",
'body':"Here's the page body, sucker"
}
# get the template path
path = os.path.join(os.path.dirname(__file__), 'index.html')
#render and output the template
self.response.out.write(template.render(path, tpl_data))
Here’s a super simple index.html template:
<html>
<head>
<title>{{ page_title.striptags }}</title>
</head>
<body>
{{ body }}
</body>
</html>
Google User Auth
Writing a user system is a pain. Making people set up new accounts to use your site is yet another barrier to experiencing your amazing new Google sellout project site. You could presumably do these things if you want in GAE, but most of the time that seems kinda stupid. GAE offers you very easy integration with Google user accounts, so you can use that as your authentication system. Since everyone and their mom has a Gmail account, it’s a pretty good bet many or most of your users will be able to skip account setup.
Pricing
GAE is free for your first 500MB of storage and “around” 5 million pageviews. That’s plenty to host a smallish app or do initial testing on something you want to get big (because big == profit, right?). If you push past that, the pricing is in-line with similar services from Amazon. That means it’s totally reasonable to set up an app just for goofing around and learning.
Python
Python is a cool language: easy to pick up and quite powerful. It doesn’t fit some tasks as well as PHP IMHO, but it does a ton of stuff well, and its large community means there is lots of support and library development. Some stuff it does really well includes:
- Network programming (example)
- Parsing HTML
- Email parsing and manipulation
- OS X scripting
- String manipulation
- Unit testing
- Other stuff I probably don’t know about
AppEngineLauncher
Recently the GAE team released the Google App Engine Launcher, an app for OS X that handles launching the development server and deploying your app to Google’s servers. You can of course script all this stuff yourself on the command line, but for folks less comfortable with that, this is a godsend. I actually did use the CLI before, but I don’t touch it now because the GAEL is just so fly. Single-click deployment is especially awesome.
Leveraging Google’s Infrastructure
They gots some big computers, rite? You’d certainly think so, and they probably have better uptime than your $5 shared hosting account. We hope.
The lame
Datastore query limitations & primitive text search
The Datastore API is GAE’s database system. It has some similarities to traditional relational DBs like MySQL and PostgreSQL, but it is fundamentally different. It stores data objects as entities instead of rows, and properties instead of columns. Objects are described by model classes, defined in Python:
class Page(db.Model):
title = db.StringProperty(required=True)
keywords = db.StringProperty()
date_added = db.DateProperty(required=True)
date_updated = db.DateProperty(required=True)
body = db.StringProperty()
Models are to entities as classes are to objects, then (I think).
The object approach has some cool flexibility, like expando models that let you add arbitrary properties to entities (very unlike rows in a relational database).
You can do SQL-like queries against the Datastore with GQL. It’s a lot like SQL, but a lot more basic. In fact, this is a summary of the entire language:
SELECT * FROM <kind>
[WHERE <condition> [AND <condition> ...]]
[ORDER BY <property> [ASC | DESC] [, <property> [ASC | DESC] ...]]
[LIMIT [<offset>,]<count>]
[OFFSET <offset>]
<condition> := <property> {< | <= | > | >= | = | != } <value>
<condition> := <property> IN <list>
<condition> := ANCESTOR IS <entity or key>
This lets you do basic queries, but it’s missing a lot of powerful stuff present in SQL. Most notably there is no equivalent to the LIKE comparison operator. That means there is no way to do partial string matches!
Okay, so you can do kludgy prefix matching, and there is an as-of-yet undocumented whole word search using the SearchableModel class, but those are primitive compared to the string matching capabilities in MySQL. Personally I would’ve thought that the search company would have given GAE really awesome text search capabilities out of the box, but for now folks have to roll their own hacks.
I guess now I have an idea of why Gmail’s search can’t match partial strings.
No “beginner” docs
GAE’s docs are aimed at experienced developers who have already built web apps. Most of it is reference, and it’s a little light on examples. If you’ve not used Python before, here’s the entire introduction form the GAE docs:
For more information about Python, see the Python website and the Python documentation.
I think Python is easy to pick up, but GAE doesn’t even bother pointing out some good tutorials for beginners. Compare this to The Django Book or The Definitive Guide to Symfony, both of which aren’t really for beginners, but do a good job of helping them get up to speed.
I’m early in my development experience with GAE, so this is by no means comprehensive. Google has already demonstrated that the GAE feature set will be growing, having introduced memcache and image manipulation APIs just a week ago. I’m sure the documentation will be improved and supplemented by third parties in short order, and the issues with text search will almost certainly be addressed soon – it’s an obvious deficiency.
For now, I’m having a lot of fun working with GAE. It’s a solid platform with a lot of promise, and it offers a lot of learning opportunities for folks who want to explore web app dev with Python.
RSS 2.0
Kibitzer says...
Really nice write-up, thanks for taking the time. I signed up for the Google Apps thing but I haven’t used it yet, so good to get some perspective on it.
I don’t get why people get so bent out of shape over indenting being part of the syntax. Srsly, who cares?