Google App Engine from a PHP developer’s perspective

My cheatin' heart

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)


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:


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.


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 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


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.

  • Kibitzer
    06/03/2008 09:55:23 PM

    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?

  • gasper_k
    06/04/2008 05:09:43 AM

    very insightful post, thanks. I’ve read a few articles on the Datastore and it requires a completely different mindset compared to a RDBMS. This is not bad by itself, but I agree that text searching should be more powerful.

  • Amanda Abelove
    06/04/2008 11:29:27 AM

    Google sellout site? laugh

  • Wesley Tanaka
    06/05/2008 02:24:25 AM

    Maybe it’s because it’s beta, but I’ve run into data store errors on GAE about as often as MySQL mysteriously disappears on $5 hosting.

  • max
    06/05/2008 03:27:18 PM

    Mind that you can develop with web2py and run on the app engine or on a normal system with mysql/postgresql/oracle seamlessly. web2py is higher level, easier and has plenty of intro level docs. Anyway, you are right about the GAE DB limitations, not much one can do about that.

  • funkatron
    06/05/2008 04:48:55 PM

    @max: Yes, I should have mentioned that you can run any framework that has a CGI interface, not just webapp. Thanks for clarifying.

  • max
    06/06/2008 09:53:58 AM

    It is true that you can any Python framework with CGI but only barebone. With Django and Pylons for example, you cannot use their native ORMs on GAE, you have to use GQL. Thus the code is not portable. This is not the case of web2py. The web2py ORM provides an abstraction layer that works with MySQL/PostgreSQL/Oracle/SQLite and GAE.

  • Drackt
    06/06/2008 01:23:40 PM

    Hey, just a note to tell you I love the image you used at the top of the post. I don’t know why but it brought me up short and I though, “Damn, that is cool.” Moving on…

  • Jimmy
    06/06/2008 01:40:47 PM

    Great article! I’m a native PHP developer and have been interested in Python ever since Django went mainstream. I’ve read a little about GAE, and it may be the tipping point which enables me to finally dive into the Python environment.

  • funkatron
    06/06/2008 02:04:28 PM

    @Drackt Thanks!

    @Jimmy Django is a nice FW, and Python is a cool language. I still love me some PHP, but the only thing that learning another language can do is expand your horizons.

  • Alex
    06/09/2008 01:10:56 PM

    What I find interesting about google is that any API/framework released seems to be in a different language? I remember learning vPython in physics when I was in college. It is a interesting language. I still prefer PHP. Nice writeup on the pros and cons

  • Adam Charnock
    06/10/2008 07:54:02 PM


    It may interest you to know that Zend and Google do seem to be talking about providing PHP support in GAE.

    For more info:

  • Shruti
    12/17/2008 06:01:32 AM

    After reading your post I found that Python is an interesting language. I don’t know Python yet but I will try it soon. Thanks for the information.

  • John
    12/25/2008 03:43:55 AM

    I found your site while searching for php frameworks. It’s interesting to hear that there is is a google app engine, I never knew about it. I better add it to

  • Adam
    08/11/2009 04:39:59 PM

    Thanks! very useful intro :D