Does no one read the documentation before deciding to use a platform anymore? App Engine supports Python 2.5. The Python interpreter runs in a secured "sandbox" environment to isolate your application for service and security. The interpreter can run any Python code, including Python modules you include with your application, as well as the Python standard library. The interpreter cannot load Python modules with C co…
I wish I could upvote this more. Implementation was a 'Square peg, round hole' architecturally.
The biggest problem for me with GAE is cost. Currently I'm paying around $150 per week for around 50k daily active users (~6 million requests per day). I'm almost sure, that i can run the same amount of traffic from $100/month dedicated server.
I'm paying a similar amount for similar traffic, and I do recall it was a bit cheaper when I had my own server. However I also recall wasting a looot of time configuring and maintaining that server. I'm willing to spend some to save time.
The biggest problem for me with GAE is cost. Currently I'm paying around $150 per week for around 50k daily active users (~6 million requests per day). I'm almost sure, that i can run the same amount of traffic from $100/month dedicated server.
There are a lot of apologists here, and they're all missing the point. Google App Engine has a large number of random issues and limitations which, while they each individually seem like they ought not to matter, add up to a substantial risk for a project running on it. I'm currently working on a project with a web component, and considered GAE. I chose not to use it, because some of the stuff I encountered in the documentation is absolutely terrifying. You're supposed to handle exceptions from the datastore? Really? The best you can possibly do is retry, but if that was going to work the library would be doing it automatically... so I guess it's saying that your app might just randomly fail sometimes. No https with a domain? I guess ever taking credit card numbers is off the table. Thirty second limit per request? Sounds reasonable, except for all the complaints about the app engine taking thirty seconds just to load the Python interpreter and compile their code. That sort of shit will sink a project; until App Engine has had a lot more time to sort out its issues and mature, I want no part of it.
One thing not mentioned is the development server slowness and need to constantly restart it. The live website actually ends up being much faster than the development site on your machine. Apparently, this is due to the fact that the development server is single threaded. TyphoonAE is one work around but then you're depending on a third-party to catch up with the latest API changes.
No, it is true. After the recent update you could use a combination of queries and offsets to retrieve more than 1000 results. To get 1001 results or more you need multiple calls.
I am sure you are mistaken. The reason I'm sure is that I just tried it: entities = data.MyModel.all().fetch(1010) print len(entities) # Prints 1010 Then I thought that perhaps you meant the limitation still exists in the low-level datastore API — and it's worked around by the Model interface making multiple calls to the low-level API — but that's not true either: from google.appengine.api import datastore entities =…
Does no one read the documentation before deciding to use a platform anymore? App Engine supports Python 2.5. The Python interpreter runs in a secured "sandbox" environment to isolate your application for service and security. The interpreter can run any Python code, including Python modules you include with your application, as well as the Python standard library. The interpreter cannot load Python modules with C co…
In my experience "instability" with GAE means you are pushing it beyond where it wants to go. If you a have code that just completes within the timeout, then guess what? When the system is under load it isn't going to complete. You can use all kinds of techniques to protect your application from things like variable datastore performance. For example, nowdays I usually use a pattern where user-facing servlets only ev…
Late September was bad for the datastore. We were seeing latency on simple queries vary from 50ms up to 5s. These were simple properly-value queries as well. This was fixed in early October I think, and a recent bit of maintenance brought latencies down even further. The datastore is now extremely fast and rarely errors out. We ( http://gri.pe ) are still happy on AppEngine, even though September was rough.
Very true. The datastore unreliability was a real nightmare. I was getting periods of 60 seconds where it was unusable...
"developing on GAE introduced such a design complexity that working around it pushes us 5 months behind schedule" This is the core of all their problems. It is a mindset incompatibility between these app designers and GAE. The GAE APIs and rules are actually pretty simple and well defined. It works really well, but only if you work WITH those rules. You have to adopt the GAE application design philosophy. If you don'…
Learning to do things the App Engine way frustrated me at first, too, until I realised in a very roundabout way it was - as you say - teaching me how to engineer for scale.
Exactly, the blog post's author doesn't seem to have realized that the limitations are simply design tradeoffs.
There are a lot of apologists here, and they're all missing the point. Google App Engine has a large number of random issues and limitations which, while they each individually seem like they ought not to matter, add up to a substantial risk for a project running on it. I'm currently working on a project with a web component, and considered GAE. I chose not to use it, because some of the stuff I encountered in the do…
It's generally not that hard to make it work well... though the datastore issues over the past few months were a real nightmare and could have (and probably did) sink a few businesses.