Google App Engine

Duncan Booth duncan.booth at invalid.invalid
Wed Apr 9 10:51:58 CEST 2008


Jason Scheirer <jason.scheirer at gmail.com> wrote:

> On Apr 8, 7:50 pm, John Nagle <na... at animats.com> wrote:
>> Duncan Booth wrote:
>> > Google have announced a new service called 'Google App Engine'
>> > which may be of interest to some of the people here
>>
>>     OK, now we need a compatibility layer so you can move apps from
>> Google App Engine to your own servers.  You don't want to be locked
>> into a single vendor solution, especially when they reserve the right
>> to start charging.
>>
>>     Their data store uses a subset of SQL, so it's probably possible
>> to write a conversion layer allowing use of MySQL.
>>
>>                                 John Nagle
> 
> It supports Django, and more importantly, WSGI, so any 'framework' you
> build on top of it should transfer out. Heck, you have a stand-alone
> python script that comes with the developer kit for hosting your apps
> on YOUR computer that you could port to use YOUR database and be done
> with it. Write your own ORM or just some decent OO code for handling
> data access so the database access layer can be swapped out and you
> are golden. I really doubt getting away from the Googe App Engine is
> going to be too terribly difficult for any intermediate Python
> programmer, assuming good up-front application design.

There are several things which would make moving away from Google tricky:

The backend data store, while it has a vaguely SQLish query language is an 
object database not a relational database, i.e. more like ZODB than MySQL. 
It uses similar concepts to django's data api but isn't the same. It should 
be possible to write something simple to replace it, but given that you 
only need to migrate away from Google when your data or page hits get 
large, you need to replace it with something scalable.

The data store is the *only* writeable storage your application can access, 
so there isn't much scope to write applications without using it.

If you use authentication then again you are tied to Google accounts (or 
Google Apps accounts). For a public application that would also block 
attempts to move to another platform.

The standalone script for testing is just for testing: it dummies out user 
authentication (login accepts anything), and it only accepts a single 
request at a time.



More information about the Python-list mailing list