Hy Luke, I released a tiny framework to manage homepage at Google AppEngine online. Once installed, you can upload and edit files / scripts without SDK.

Nice, really.
Many like me have tried and realized the same as in this blog:-
http://bygsoft.wordpress.com/2010/01/09/cloudy-combo-google-app-engine -and-amazon-s3-combo-pack/

[…] Pretty tough set of requirements to meet, but I do have a solution for you. It’s called Google App Engine which as you may or may not remember is one of my favorite things on the interwebs. […]

I have to say, you did a really nice job on explaining something that can be really tricky at times. There are times that I struggle with wrapping my head around topics like the this, thank you for summing it up well.

Thanks!

if you watch the video presentations from google io, the datastore lead walks through some hacks to implement aggregate type functions and many to many relationships — they’re ugly hacks, though the many to many is passable if your data model is going to be less than or equal to 1000 to 1. the aggregate hack is fugly and violates any aspect of atomicity. worse, if you mess up, there is literally no way to repair your data.

now, on the google group forums, there is quite a bit of clever engineering around those restrictions by chaining requests.

i’m rooting for them to succeed but given current platform features, i doubt anybody will use other than some toy apps. and given the traffic i see on the google group boards, it doesn’t appear that developers are exactly flocking there…

another point i didn’t mention is that there is a cap on each transaction even if you are under the DB call quota you still can be flagged for excessive CPU. for example, i coded a simple app that does ONE DB FETCH and unpickles/pickles (Python equivalent of PHP serialize, Ruby marshal) a 200K object graph for which my logs show that i exceed the minimum quota and will be charged out of another queue that could shutdown my app. they don’t list the caps for that special bucket either, so i guess it’s at whim for now…

batch job or some sort of DB export/import is needed… …in 2008, just not customer friendly to not offer migration/export function and that limits appengine to just a toy that will get some oohs and ahs for things like wordle but fairly limited in what can be accomplished (how many bookmarking/vote a link sites do we really need?)

Very good points. The lack of aggregate queries in GQL is indeed incredibly annoying. I think the idea is to do a SELECT * and then aggregate in your code or something – which is boneheaded. I’m guessing since the indexes are just flat files like you said, they just can’t delegate this sort of thing to the database – and perhaps they didn’t feel like implementing parsing for the COUNT(), AVG() and etc seeing how it would still boil down to a select statement and a simple loop.

I never really expected cron-job like behavior on this service. I think it is one of those limitations I talked about. But you are right – most people would be perfectly happy with a quota of some sort – even if it was 1 operation per hour. But this sort of thing is ripe of abuse so I’m not surprised they didn’t offer it.

#3 is interesting – Jaiku is moving to Google apps. I suspect they are not bound by these limitations. So it’s possible that in the future Google may offer Pro accounts without these limits.

As for #4 you pretty much answered it. Even though their framework is limited, you can easily drop in and use another one – as long as you can get it working with the data store, and change all calls to urllib2 into urlfetch :P

been meaning to do a writeup of GAE as I have tinkered a bit with it, and generally like it, but there are severe shortcomings if the platform is to be used for anything other than non-trivial toy like applications…

it’s also rekindled an interest in python, which I did some coding in nearly 10 years ago, way back before python v2 even existed. oddly, my coder brain seems to wrap itself around python much more naturally than ruby, which i love too (but recognize its warts)…

first the GOOD:

1. as you’ve alluded to, drop dead simple to develop, without all the annoyances and grievances of deployment. one-click upload and deploy.

2. open to using whatever platform (well, at least the controller/view deal, not the database implementation, which you can modify a library of your choosing but you stuck with GQL scheme (which has serious drawbacks as I explain further down))

3. python is a great language and though some complain about lack of alternatives, python works for me

4. auto user functionality built-in

however, app engine is an immature platform and faces obstacles for any serious usage:

the BAD:

1. the datastore model – you’re really limited to a indexed flat file / single table storage deal. no joins (which i don’t have a big beef with), 1000k fetch limit (you shouldn’t really be doing more DB access in an online transaction!) — those are not show stoppers. what is, is that you are unable to do (1) aggregate functions like count, average, sum, etc… without hacking in a inelegant solution that totally violates atomicity. worse, if you mangle the DB (as i will get to #2 in a second), no way to really clean it up… in terms of table relations, you can have foreign keys and even setup a many to many scheme, but it’s fugly and again you will have to tread carefully and clean up yourself after deletes, and still are limited to 1000:1 ratio

2. #1 wouldn’t be bad if you had capacity to run background/batch jobs (not asking for ever-executing daemons, just cron type scripts to run and perform summarize | DB scrub | etc….). I understand that the Google Lords don’t want people spidering the entire net, but they could limit such executions to 15 (or 10 or whatever cap) minutes or less and still charge for the CPU|GPU cost incurred…

3. without ability to do serious work in a transaction, how is it possible to bulk upload? even data files are limited to 1M. in a toy app i coded, i needed to hit /usr/share/dict/words and in the virtual space provided, didn’t see how to get it on server but had to restrict my word list to less than 9 chars so the file could fit under 1M…

4. the given examples use a webapp framework that is really limited when it comes to handling sessions, cookies or anything more detailed than a simple app with a handful of pages. this can easily be mitigated as Google themselves have a Django app-engine helper that makes it easy (though it’s still a scaled down Django without the models, middleware, and other parts). i would highly recommend using that or employing web2py (or another simple python framework like web.py).