>> 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... 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.
>> 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.
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... 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.