

Example using Google App Engine's new Remote API - DocSavage
http://billkatz.com/2009/2/Remote-API-Hello-World

======
DenisM
This looks of limited utility. Why would I want to process data away from
where it is stored?

~~~
DocSavage
Right now, you can't run long-lived processes on App Engine, so schema
changes, backups, and a whole raft of data processing routines must be handled
through the HTTP interface. The remote API abstracts that away so you can
write scripts as if you were operating locally without those limitations.

Also, the remote API could potentially be used with any other App Engine API,
not just the datastore API.

There have been a number of App Engine enhancements over the last few months:
a hook system, sorting on keys, this remote API, and most importantly, the
relaxation of CPU limits. When taken together, these enhancements will allow
some pretty cool management apps purely in user space.

~~~
DenisM
>> The remote API abstracts that away so you can write scripts as if you were
operating locally without those limitations.

But you still have to write the code assuming it can be interrupted by network
going down etc. Once you do that, you might as well run it next to the data,
no?

I can see the CPU-intensive argument, but this is less important now given
relaxation of CPU rules.

Also, consider this paper by Jim Gray:
[http://dslab.epfl.ch/courses/pods/fall06/readings/gray-
econo...](http://dslab.epfl.ch/courses/pods/fall06/readings/gray-
economics.html) where he concludes from economics point of view: _Put the
computation near the data. The recurrent theme of this analysis is that "On
Demand" computing is only economical for very CPU-intensive (100,000
instructions per byte or a CPU-day per gigabyte of network traffic)
applications._

~~~
DocSavage
>> this is less important now given relaxation of CPU rules

If you run on the server-side, you are still severely limited by request time
limits, so you'll have to move the outer loops off App Engine. I already wrote
a REST api to my app, and it'll still be used for AJAX clients and routines
and authorization-specific scenarios. But for schema migrations,
backup/restore systems, and quick and dirty prototype apps, the remote API
simplifies the programming.

> Also consider this paper by Jim Gray

I don't dispute the bottom line of putting computation near the data... if
your app is computation-driven or each computation requires mondo data. Ease
of programming against the datastore shouldn't be casually dismissed in favor
of architectural ideals, particularly in the context of free app quotas and
programmers who want to quickly hack up a web app or prototypes.

