Google App Engine beta

Easy dynamic Web sites

Google App Engine beta
  • Expert Rating

    4.00 / 5


  • Fast and easy Web-app development, uses Google's cloud of computers


  • API not as rich as Amazon's SimpleDB, limit on resources

Bottom Line

It is almost unfair to review the Google App Engine when it is just a beta operation, but Google has a habit of leaving some tools in beta form for a long time. There are a number of places where the documentation and the code suggest that Google will add more functionality pretty soon. The basic framework and the database are both quite nice, although limited. We can imagine Google adding better automatic features for generating the CRUD (Create, Update, Delete) routines common in these applications. Integration with Google's Wallet might also be quite useful, although it's bound to be complicated by the banking system. Some people have already experimented with mapping the Google Web Toolkit to the system, even though that's written in Java and translated into JavaScript. Google might also provide some good tools that allow the different hosted applications to share user information, in essence allowing a user to move their preferences and some of their data to other applications. This kind of inter-application linking could be pretty cool. Time will tell what Google delivers. In the meantime, this is a good sandbox for playing with simple database applications. There's a very good reason why the beta version has a waiting list.

Would you buy this?

Smells like SQL

It's probably best to think of the system as a thin layer of business logic in front of a simple database, the kind that DBAs like to call a "data store" to emphasise the point that you can't do most of the complicated things that Oracle allows. The database is nicely integrated with Python but it only offers the kind of basic search and store functions that developers will need to squirrel away their user's information.

You set up the data objects in Python, hit the save method, and the data disappears into the cloud where all of the instances of the application can find it. The language is pretty close to SQL, but it comes with a slightly different syntax, which means that you won't be able to use any of the millions of tools that sort of speak SQL to generate reports or produce graphs.

Furthermore, the data store API doesn't include old-fashioned joins, an omission that will break some of the code written for traditional databases. The simplicity is nice, but there's a reason why everyone ends up using standard databases for the core of their projects.

So there is a certain amount of lock-in hiding in the API. Porting your application to something like MySQL won't be automatic but we doubt it would be hard at all. Going in the other direction, though, could be both healthy and annoying. Because there's no way to join tables, you're effectively forced to denormalise your tables. Most web developers end up doing this eventually to help things scale, so we assume it makes sense to start out that way even if it seems a bit messy.

There are omissions. The documentation mentions web services and AJAX (Asynchronous JavaScript and XML), but there's very little support for them out of the box. Perhaps there will be some grand catalogue encouraging mashups in the future. It would also be nice to offer some basic templates for data structures so that most of the applications could begin with the same standard formats for dates, locations, and other things. Currently you don't get much beside the simple Python application framework with a bit of MVC (model-view-controller).

Nor are there many of the tools that might be essential. The samples and the tools all run through the command line, probably the preference of the developing team. We can see that developers might want more sophisticated tools for profiling the code and tracking every click. Google suggests profiling by dumping the profile information between tags in an HTML document. Using tags would probably confuse the command line jockeys.

Sky's the limit

The plan is to charge when applications exceed some limits, a perfectly fair plan but one that makes me a bit nervous after years of basic pricing for servers. The terms and conditions suggest that you only get "200 million megacycles of CPU per day".

You can see a snapshot of resource consumption, but this seems like an especially squirrelly metric that could be skewed in odd ways by factors beyond the developer's control. If you send a weird query to the database, it may burn cash in a way that you didn't anticipate.

One of the biggest headaches for Java programmers comes when an instance of an application on one server starts asking for data that happens to be sitting on another server. Inter-server communication can slow fast boxes to a crawl, and entity locking could get scary if two users start nibbling at the same bytes at the same time.

We know we should be happy that App Engine will bring up new servers when the demand arrives, but all we can think about is watching the meter spin when an errant query starts chasing down data on other servers. Getting wildly popular may turn out to be more of a nightmare than a dream because Google will dutifully roll out more versions of your applications, burn more megacycles, and put it on your tab.

We're sure Google will come up with ways of limiting the size of the bill, but all we can think of is firing up a slick website and repeating Woody Allen's line from Manhattan: "God, you're so beautiful we can hardly keep my eyes on the meter."

Google also lets you access Google accounts, the creepy feature that links your search history with your Gmail account. The users of your application don't need to set up a separate log-in or a separate account. You can get a user object with all of this information when they show up, if they've recently been logged in to read their Gmail. If you don't want to use this feature, you could always spin up your own user accounts with the database, of course.

Some of the FUD spread by rival camps suggests that Google just wants to use App Engine as a way to nurture Python developers so that the company can hire them away. Others see it as a cynical way to gain control and lock people into their Google accounts. Others think this is just a technique for Google to build a big plantation with you, the Python developer, toiling away to monetise its app cloud and add more value to the Google account.

Rocket to Success - Your 10 Tips for Smarter ERP System Selection

Join the newsletter!

Error: Please check your email address.
Show Comments

Most Popular Reviews

Latest News Articles


PCW Evaluation Team

Ben Ramsden

Sharp PN-40TC1 Huddle Board

Brainstorming, innovation, problem solving, and negotiation have all become much more productive and valuable if people can easily collaborate in real time with minimal friction.

Sarah Ieroianni

Brother QL-820NWB Professional Label Printer

The print quality also does not disappoint, it’s clear, bold, doesn’t smudge and the text is perfectly sized.

Ratchada Dunn

Sharp PN-40TC1 Huddle Board

The Huddle Board’s built in program; Sharp Touch Viewing software allows us to easily manipulate and edit our documents (jpegs and PDFs) all at the same time on the dashboard.

George Khoury

Sharp PN-40TC1 Huddle Board

The biggest perks for me would be that it comes with easy to use and comprehensive programs that make the collaboration process a whole lot more intuitive and organic

David Coyle

Brother PocketJet PJ-773 A4 Portable Thermal Printer

I rate the printer as a 5 out of 5 stars as it has been able to fit seamlessly into my busy and mobile lifestyle.

Kurt Hegetschweiler

Brother PocketJet PJ-773 A4 Portable Thermal Printer

It’s perfect for mobile workers. Just take it out — it’s small enough to sit anywhere — turn it on, load a sheet of paper, and start printing.

Featured Content

Latest Jobs

Don’t have an account? Sign up here

Don't have an account? Sign up now

Forgot password?