Behind the scenes of these GAE applications is a type of database that Google created called the Datastore. Early in the development of GAE, it didn't take long to find posts listing a number of concerns about the Datastore and how limited it seemed to be. The Datastore is a radical departure from the usual RDBMS (relational DMBS) we've all come to know inside and out.
Google describes it as a multidimensional sorted map. For hardcore database developers, that sounds pretty limiting. I don't know if Google anticipated the resistance, but blog comments usually revolved around, "Yes, but I can't do such-and-such." Typically somebody would post such a question, and then others would respond by showing just how you really could do such-and-such, with a little bit of shift in thinking.
For example, the Datastore limits your result sets to 1,000 rows per query. In addition, the concept of relations is gone. To many of us, that would seem to make the Datastore basically unusable.
However, the approach isn't to start with a relational design and come up with workarounds, but rather to redesign from scratch under the new approach. When you do that, you end up with a database system that is, some bloggers have said, "blindingly fast." The blog post linked here also suggests that writing data isn't as fast as it is in relational databases.
That may be true, but does it matter? When you write data to a database through a Web application, you often don't have to sit and wait for the results. For example, if you are composing an e-mail in a site such as Gmail, you can click the send button. Google can immediately take you to the next page, showing the mail as sent. Behind the scenes, Google may not have finished saving the data to your sent box. Either way, you can continue with your next task. (Readers of this article will certainly think of specific examples where you do need to immediately find out the results of a database write, but I'm talking about general-purpose Web applications used by the masses.)
When you're reading a database, on the other hand, you typically don't want to wait. Type something into Google and notice how fast you get your response. It's pretty much instant. Then think of the millions of other queries that were likely taking place at the same time yours was, and it's really impressive. If there's a tradeoff between write speed and read speed, write speed should win from a usability standpoint.
What, then, are my final thoughts about Google App Engine? I saw some really cool applications, and I saw some that weren't at all impressive. None of the applications demonstrated any massive power. However, there are some things to consider here. For one, the applications are all running on Google's servers together; they aren't hosted individually. That means while many of them might not have a lot of activity at any given instant, all the applications combined may together have a great deal of activity. They all seemed just as fast as any other good sites out there.
Combine this with the defense that Google's Datastore is incredibly fast, and the fact that these applications are running on Google's tried-and-proven servers. I would conclude that even though there might not be many really powerful applications written in Google App Engine yet, as more developers start using GAE, we are sure to see some. (And those existing ones that I found may become immensely popular.) I would guess these applications will, quite likely, perform very well compared with non-GAE apps like Facebook and Twitter.
My conclusion, then, is that Google App Engine is a totally viable platform for large Web-based applications.
Senior Editor Jeff Cogswell can be reached at jeffrey.cogswell@ZiffDavisEnterprise.com.