Espians: Why App Engine Is Not Appropriate For Bootstrap
thruflo
· 6 months ago
The crux of the App Engine matter is that it is what it is.
It's designed to support a certain class of app. As the dev team behind it iterate, it may become appropriate for more apps. The decision to use it must be bound to the specific use it needs to support.
For what it's worth, 30 sec request limit makes sense for the type of apps they've designed the platform for, the task queue api limit will clearly increase soon, possibly infinitely (at a cost). Keys_only seems like a pretty good entitiy loading workaround and downtime? You think you can do better?!
The map reduce pattern is on the dev teams' radar and the async is like it is bc they, too, have bills to pay.
tav
· 2 months ago
Ryan Barrett — the man behind App Engine's datastore posted a really nice reply a few months ago. For some reason, Disqus sent the reply via e-mail but never showed it here, so here it is for the sake of completeness:
--------------------------------------
thanks for the post! we're always interested in well-reasoned feedback like this.
it probably won't surprise you that most of the answers here boil down to priorities. we'd love to implement most of these, but we're not a big team, so we have to prioritize ruthlessly. i can address a few points specifically, though.
2) agreed! unfortunately, datastore backend support for this is unlikely due to the underlying implementation on bigtable. happily, this is entirely possible in userland. my groups post has more details: http://groups.google.com/group/google-appengine... . brett slatkin's recent i/o talk is also related, specifically the relation indexes/entities part: http://code.google.com/events/io/sessions/Build... .
3) we actually considered this, and we may reconsider it in the future. the actual savings would be negligible in most cases, though. the only meaningful part we could remove is some of the protocol buffer encoding decoding and maybe one or two of the RPCs. the bulk of it, including the underlying datastore cost, would be unchanged.
5) i'm very much looking forward to offering more async support in our APIs. in the meantime, check out vendasta's asynctools project, http://squeeville.com/2009/07/24/asynctools/ .
6) we actually posted an in-depth postmortem less than a week afterward: http://groups.google.com/group/google-appengine... . regardless, agreed, we hate outages as much as everyone else. we're continually working to avoid and minimize them.
All Comments
It's designed to support a certain class of app. As the dev team behind it iterate, it may become appropriate for more apps. The decision to use it must be bound to the specific use it needs to support.
For what it's worth, 30 sec request limit makes sense for the type of apps they've designed the platform for, the task queue api limit will clearly increase soon, possibly infinitely (at a cost). Keys_only seems like a pretty good entitiy loading workaround and downtime? You think you can do better?!
The map reduce pattern is on the dev teams' radar and the async is like it is bc they, too, have bills to pay.
--------------------------------------
thanks for the post! we're always interested in well-reasoned feedback like this.
it probably won't surprise you that most of the answers here boil down to priorities. we'd love to implement most of these, but we're not a big team, so we have to prioritize ruthlessly. i can address a few points specifically, though.
2) agreed! unfortunately, datastore backend support for this is unlikely due to the underlying implementation on bigtable. happily, this is entirely possible in userland. my groups post has more details: http://groups.google.com/group/google-appengine... . brett slatkin's recent i/o talk is also related, specifically the relation indexes/entities part: http://code.google.com/events/io/sessions/Build... .
3) we actually considered this, and we may reconsider it in the future. the actual savings would be negligible in most cases, though. the only meaningful part we could remove is some of the protocol buffer encoding decoding and maybe one or two of the RPCs. the bulk of it, including the underlying datastore cost, would be unchanged.
5) i'm very much looking forward to offering more async support in our APIs. in the meantime, check out vendasta's asynctools project, http://squeeville.com/2009/07/24/asynctools/ .
6) we actually posted an in-depth postmortem less than a week afterward: http://groups.google.com/group/google-appengine... . regardless, agreed, we hate outages as much as everyone else. we're continually working to avoid and minimize them.