Google App Engine teases, but ultimately doesn’t deliver

This blog should perhaps have been named “My Rants” – but I guess that could be said of most blogs.

In case it’s not obvious yet, this is officially a rant.  But I will try to keep it short, an “Executive Summary” rant, if you will. In fact, that’s all I have energy for anyway.

Sling a stale slice of pizza, and you’re sure to hit a slew of twenty-somethings that will tell you what a “super cool” language Python is and what an “awesome” platform Google App Engine is. Perhaps they’re right.

I won’t go into the Python language here. I will, however, simply quote from the unpublished rants of a well-known and well-respected author I was recently re-reading:

I think they should have just named the language “Underscore”.. and the source files could have a “._” extension.

However, Python is not the worst of GAE’s problems, not by a long shot. In the name of executive summary brevity, I’ll jump right in.

  1. “GQL” and the Datastore – I don’t know who Google is trying to kid here by hinting that the “datastore” is somehow like “SQL”. God help you, if you fall into that trap. It must drive any real RDBMS expert mad.
  2. urlfetch – only works on port 80 or 443 and times out after a few seconds.
  3. mail.send() – can’t send to more than a few addresses at a time, whether invoked once for all recipients, or using multiple invokations.

All the above should be prefaced in the GAE documentation, in huge red letters: DO NOT EXPECT THIS TO WORK because they don’t, at least not in practice to do anything real.

In theory, Google says a request can run for up to 10 seconds. In practice, it never will because it will hit quotas before that, or it will fail because of urlfetch timing out if it makes calls to web services (like Twitter API, Facebook API, or whatever) on the back end.

Without this basic functionality, there isn’t much a GAE app can actually do, especially if it gets popular.  Without these functions, your app can’t connect to anything. It’s like a computer without the Internet – not very useful. And the worst of it is, you don’t find out they don’t work, until you get to the point of trying to actually use them, which means you’ve already put in all the effort to learn the platform and write code for it.  I say, for now at least, don’t waste you’re time, unless you are really bored and like punishment.

If your app is small enough, and doesn’t do much more than generate slightly dynamic content using templates, it might work on GAE.  Otherwise, stick to a real platform. Paraphrasing the words of a co-developer:

I think we’re at an inflection point:  forge ahead with GAE culture, or spend that time scaling and fortifying the app somewhere else.  I mean, if our app really takes off, we are unequivocally screwed on GAE; run over by a truck.

Google App Engine has promise, if they can resolve these issues (and a number of others I’m leaving out). It comes down to whether Google will get serious or not and that’s not their style or history, so we’ll see. This cannot be just another “G” self-service, zero-support platform, if they ever want to support real companies deploying real applications and services.

At the end of the day, Google teases, one might even go so far as to say tricks us, into believing they are providing a platform of substance and merit, only to disappoint those of us who took them at their word.

See Also: Aral Balkan – Why Google App Engine is broken and what Google must do to fix it.

2 comments for “Google App Engine teases, but ultimately doesn’t deliver

  1. I totally agree. I’ve just wasted a couple of days learning how to use JDO in the Java Google App Engine only to discover that even the simplest of operations time out or hit quotas. The worst thing is that everything works fine in the eclipse simulator but only goes wrong on the live deployment. Totally sucks. So much promise and such a disappointment.

Comments are closed.