Re: Google App Engine

Jason Scheirer <jason.scheirer@xxxxxxxxx> wrote:

On Apr 8, 7:50 pm, John Nagle <na...@xxxxxxxxxxx> 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.
.

Relevant Pages

  • Re: Apples poor positioning for the age *after* x86
    ... You might argue that Google is solving the wrong ... What's a message board, and what's a message.... ... What explicit product searches do you mean? ... > were routinely old 16-bit apps and installers to deal with. ...
    (comp.sys.mac.advocacy)
  • Some architecture advice
    ... I've used business objects for a while, ... make apps that are more maintainable. ... using a "bridge" pattern. ... On the UI layer I'll use a set of classes as a "facade" to ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Some architecture advice
    ... > I've used business objects for a while, ... > make apps that are more maintainable. ... each layer is independent of one another and each ... > Being relatively inexperienced with architecture I'm sure ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Delphi refocussing on .Net - good or bad?
    ... they manage to put a UI layer on top that uses un-accelerated graphics and is sluggish as heck - instantly proving the opposite of what's actually true: that .NET is much slower than managed code. ... On the flip side you have WPF, which even 2 years after release isn't properly supported with decent design tools, performs pretty bad unless you have state of the art hardware. ... Windows (and other Widnows apps) cant use the stuff the Office team developes, and developers need to clone their own Office menu items or their own Ribbon, etc. ...
    (borland.public.delphi.non-technical)
  • Knuckle Under to Telcos
    ... Google, Apple and Microsoft Knuckle Under to Telcos ... commandments for developers working on apps for the upcoming ...
    (alt.gathering.rainbow)