[Python-talk] Google app engine

[Kent Johnson]

Christopher Schmidt wrote:
> On Wed, Apr 09, 2008 at 09:46:58AM -0400, Kent Johnson wrote:

>> - vendor lock-in - apps written for GAE will not run anywhere else, you 
>> have to code to the Google APIs
> 
> How so? I'll admit that the Fetch API is somewhat esoteric, and the
> datastore is somewhat limiting, but not painfully so. It runs WSGI
> applications, so any app that's WSGI can be made to work reasonably
> easily.

That is a bit simplistic IMO. If your app uses persistent data it will 
use the datastore APIs. This is the biggest source of lock-in. User 
authentication, sending email and external fetch also require you to use 
Google APIs. I don't think this is such a big issue because these 
aspects are not as pervasive as the data model.

Any Django or Pylons or TurboGears app can be run under WSGI; are you 
saying they could be made to work under GAE 'reasonably easily'?

> Additionally, you can 'just write Django' and do pretty well,
> from my reading of the docs: again, you have to do some work to 'fix'
> your data model, but if it's written that way from the beginning, it
> wouldn't be too bad to go *away* from GOogle (it's just going *to*
> google that's hard.) 

You don't fix the data model, you rewrite it. What do you mean by 
'written that way'? How would you migrate an app that uses the datastore 
away from GAE to, say, Django ORM? Why is it harder to migrate to GAE 
than away?

Granted there is already interest in making a Django database backend 
for GAE, and in making wrappers for e.g. CouchDB that use the datastore 
API, so the migration story will probably improve, but today I think it 
is hard.

>> - datastore - the datastore is based on Google's BigTable. It is not a 
>> relational database. It does support foreign keys but not joins. To me 
>> this suggests that using a complex data model might be cumbersome and 
>> inefficient.
> 
> Possibly, but I think that limited datastore APIs are not entirely
> different from the step from SQL->ORM: you abandon a bit of flexibility
> for a lot of benefit, and for many applications, I think that the same
> thing applies: BigTable hits a fair number of use cases without being
> difficult.   

Yes, I'm not saying BigTable is bad, but I think it does have a 
different sweet spot than, say, Postgres. I have an app that frequently 
does three- and four-table joins, I'm not sure how I would write that in 
GAE datastore. I imagine it would require some thought and re-architecting.

Kent