I've been playing with the Google App Engine SDK in recent weeks, starting to build an app that will scratch a personal itch of mine (more of which at a later date, when I'm closer to deploy). Anyway, I'm keen to share my early experiences.
So what's the Google App Engine? It's basically a platform that allows you to build web applications that can be hosted on Google's (enormous, secure, resilient) infrastructure. For free. Well, you get a pretty large quota of resources for free, and you can turn on billing to pay for any more your app may need. There is database support in the shape of Bigtable, support for secure http, and even the ability to run scheduled jobs (cron jobs). However, there are some restrictions: you can't open a socket, and threading is disabled for example. At the moment the supported languages are Python and Java. I chose Python (version 2.5 is implemented in the App Engine).
With Python comes Django (you can develop App Engine apps without it, but I like Django). Lots of people seem quite upset that its only Django 0.96, although the most recent SDK (version 1.2.3) supports version 1.0 albeit that you have to explicitly state this in your code. The default remains at 0.96. It doesn't bother me, so I use Django 0.96 - it'll be interesting when the default changes from 0.96 to 1.0 to see how this is managed by Google (I'm trusting that my app won't just break one day). There are also some bits of Django we lose; for instance models are replaced by Google's database module and as a result the Django Admin application doesn't work, and session management is broken.
So how to manage session data? We can go back to cookies or we can use the Memcache, Google's distributed in-memory data cache. I like the Memcache.
Any other draw backs so far? The database doesn't support full text search, and the SQL implementation doesn't have a LIKE operator, so I've had to do a workaround in order to implement an AJAX autocomplete form field. And there's no transaction support... or is there? You can actually perform multiple database updates as a single unit of work, but to do it you have to sacrifice some of the distibuted nature of your data. Data can be grouped on a single database node by specifying a parent entity (the root for the group) when saving another entity. Transactions can be performed within this group. It's a bit like the old principles of CODASYL database 'sets', which I learned from my grandfather. I guess you have to think about design to get it right, Google recommends not to implement more than one 'customer' worth of data in a single group.
All in all I think that the Google App Engine could be a great way for developers to get an idea off the ground without incurring huge costs in the early stages of a project. I'll let you know how things develop from my own early stages.
In its current guise, I am not a big fan of Google App Engine.
ReplyDeleteIt’s a pain in the neck for App Engine to only support python (apparently PHP et al will follow soon) and limiting external URL requests to 4 seconds is a little draconian, lets forget the fact that you have to use the Gmail mail delivery service and that there is no SQL database available. While all of these are rather limiting they are not the real reason why I don’t like App Engine….it’s because of vendor lock in and the lack of any interoperability with other cloud providers. Google is a big company who will probably dominate this market…they can afford to do better in this area, but they seem to choose not to…Is Google evil?
That doesn’t mean that I am not interested in how App Engine is developing. The service has some incredible advantages over the AWS model if you run a website. Using App Engine you would simply upload your web files and let the system scale for you as opposed to AWS EC2 customers would need to launch multiple servers and install all sorts of stuff. Obviously, if you need more than simply web hosting then the service is somewhat lacking (email delivery is a problem and file access is limited).