Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye, Google App Engine

carlosble.com

Post reply on HN
Print view View original

41–50 of 102 posts

Re: Goodbye, Google App Engine

#41

Post by ajkirwin »

nl wrote: post #31

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…

That whole article was, to me, just a list of "Yep, already knew that" and "Yep, I was already taking that into account."

The person just seems like.. I don't know. Kind of stupid, to be honest. I mean..

"Datastore and memcache can fail sometimes." YOU DON'T SAY. "Memcache values max size is 1megabyte. Wanted to cache everything? You were just dreaming mate, just 1 megabyte." Who the hell is putting >1mb things into MEMCACHE? That's NOT WHAT IT'S FOR.

And the fact their thing was taking >1 second? That sounds horribly poorly done. I started getting concerns when my last site was taking a few hundred milliseconds.

Some of the terms they use also make me think they have inflated self-opinions. I mean "software craftmen"? Really?

Re: Goodbye, Google App Engine

#42

Post by mmastrac »

nl wrote: post #40
dantkz wrote: post #36

Earlier quoted context omitted.

In the comments he says that the restrictions were not THE problem, THE problem was the instability. List of restrictions is kind of reminder of what he had to cope with, and wasted money on, until it turned out that GAE doesn't work properly.

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.

Re: Goodbye, Google App Engine

#43

Post by X-Istence »

sahillavingia wrote: post #4
checker659 wrote: post #2

#11 isn't true. Since a recent update, you can now retrieve more than 1000 results in a single call.

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.

No, you can set limit in a fetch to whatever you please and the datastore will return all those results to you ... the 1000 limit was removed.

http://code.google.com/appengine/docs/python/datastore/query...

Where does it say that 1000 is the limit?

Re: Goodbye, Google App Engine

#44

Post by nir »

The article mostly describes obvious, well documented limitations of GAE. It's really the story of a team that needed a saw, picked a hammer, and spent months trying to get it to cut wood.

This is a pretty common pattern in software, so it might be more interesting to write an article about why they chose the wrong technology and how they stuck with it even with it was clear it wasn't built to do what they needed.

Re: Goodbye, Google App Engine

#45

Post by tonyarkles »

krosaen wrote: post #34

This hasn't been my experience. Yes, existing techniques for full text search works or things like geolocation queries won't work but there are other[1] techniques[2] that work just as well; it's just not the sql way. Basically, support for multiple set membership queries against a list of tags stored with entities is extremely powerful and if you index properly, you can do a lot of cool things [3]. Plus, you can do…

Cool! People know about asynctools and are using it! That was developed by a friend of mine at a previous job. Glad to see it's useful.

Re: Goodbye, Google App Engine

#47

Post by revoltingx »

I'm writing an MMORPG for Android and when I started I carefully examined GAE.

I find that it's only really useful for a narrow use-case. One thing, you're tied to either the JVM or Python, which is ok it's just requirement #1.

It's meant for web apps. You can't open sockets or write to files directly. You do long running jobs using cron jobs. That's too slow for me, last time I checked the shortest job interval in cron is 1 minute.

With a message queue software such as beanstalk or rabbitmq I can get background jobs started in milleseconds.

Your app has to be somewhat simple to work with this. Plus it just won't have that super snappy feel to it.

Honestly, anything that doesn't give you root is like working with a used canvas. Someone has written all the lines but you have to stay within the boundaries.

EC2 or Linode are a much better solutions to start with. If your app is to scale you should aim at running on dedicated hardware on a dedicated line in a datacenter. With a root environment you can make this transition much easier.

I don't see why people are so scared of administrating their machines with root. If you are a developer you should know how to do all the server setup stuff naturally. You should be comfortable compiling software from source. You will be so much more valuable if you know how to be an administrator and a developer.

Re: Goodbye, Google App Engine

#48

Post by Kilimanjaro »

krosaen wrote: post #34

This hasn't been my experience. Yes, existing techniques for full text search works or things like geolocation queries won't work but there are other[1] techniques[2] that work just as well; it's just not the sql way. Basically, support for multiple set membership queries against a list of tags stored with entities is extremely powerful and if you index properly, you can do a lot of cool things [3]. Plus, you can do…

"the image hosting infrastructure that provides fast access to different sizes for a stored picture based on a url is pretty slick"

Any links? I am saving both pics and thumbs and that info would help me a lot.

Re: Goodbye, Google App Engine

#49

Post by krosaen »

tonyarkles wrote: post #45
krosaen wrote: post #34

This hasn't been my experience. Yes, existing techniques for full text search works or things like geolocation queries won't work but there are other[1] techniques[2] that work just as well; it's just not the sql way. Basically, support for multiple set membership queries against a list of tags stored with entities is extremely powerful and if you index properly, you can do a lot of cool things [3]. Plus, you can do…

Cool! People know about asynctools and are using it! That was developed by a friend of mine at a previous job. Glad to see it's useful.

yeah, I've written a wrapper around it so we can post process the results and memcache that, but asynctools has been really useful!

Re: Goodbye, Google App Engine

#50

Post by krosaen »

Kilimanjaro wrote: post #48
krosaen wrote: post #34

This hasn't been my experience. Yes, existing techniques for full text search works or things like geolocation queries won't work but there are other[1] techniques[2] that work just as well; it's just not the sql way. Basically, support for multiple set membership queries against a list of tags stored with entities is extremely powerful and if you index properly, you can do a lot of cool things [3]. Plus, you can do…

"the image hosting infrastructure that provides fast access to different sizes for a stored picture based on a url is pretty slick" Any links? I am saving both pics and thumbs and that info would help me a lot.

yeah, check out "get_serving_url" on:

http://code.google.com/appengine/docs/python/images/function...

Post reply on HN