Is Google App Engine right for me?

Asked 14/12, 2009 at 19:51 Answered 3/1, 2010 at 11:57

I am thinking about using Google App Engine.It is going to be a huge website. In that case, what is your piece of advice using Google App Engine. I heard GAE has restrictions like we cannot store images or files more than 1MB limit(they are going to change this from what I read in the GAE roadmap),query is limited to 1000 results, and I am also going to se web2py with GAE. So I would like to know your comments.

Thanks

Sulfate answered 14/12, 2009 at 19:51 Comment(5)

depends on your requirements... – Pandemonium 14/12, 2009 at 19:53

all the information is public... so you can do more than "hear about it"... you can "read about it" too ;-) – Pandemonium 14/12, 2009 at 19:54

Are you actually planning to ask a question? I have been using GAE for a number of projects and I really like it, but it's a completely different kettle of fish from using a LAMP stack. I would suggest playing around with it and getting a feel for it. – Truscott 14/12, 2009 at 20:0

What exactly would you like to know about? It's difficult to answer this based on what you've said. – Massarelli 14/12, 2009 at 23:11

50MB blobs are now supported: googleappengine.blogspot.com/2009/12/… – Snot 15/12, 2009 at 6:46

Having developed a smallish site with GAE, I have some thoughts

If you mean "huge" like "the next YouTube", then GAE might be a great fit, because of the previously mentioned scaling.
If you mean "huge" like "massively complex, with a whole slew of screens, models, and features", then GAE might not be a good fit. Things like unit testing are hard on GAE, and there's not a built-in structure for your app that you'd get with something like (famously) (Ruby on) Rails, or (Python powered) Turbogears.

ie: there is no staging environment: just your development copy of the system and production. This may or may not be a bad thing, depending on your situation.

Additionally, it depends on the other Python modules you intend to pull in: some Python modules just don't run on GAE (because you can't talk to hardware, or because there are just too many files in the package).

Hope this helps

Consecration answered 15/12, 2009 at 1:1 Comment(5)

Not entirely true about staging: You can deploy an alternate major version, test it, then set it live if it works. – Massarelli 15/12, 2009 at 9:20

Nick is right. If you are wondering, you can go to "versions" in the left hand pane of the app dashboard. There you can set which version you want "live". You can also find urls for the other version so you can test them before setting them loose on the world. – Truscott 15/12, 2009 at 9:45

And unit testing is not too bad in my experience with nosegae (code.google.com/p/nose-gae) and webtest (pythonpaste.org/webtest). – Outrageous 15/12, 2009 at 12:0

you can usually zip up the module, so it only counts as one file – Skier 6/3, 2010 at 4:36

@RyanWilcox, I dont see how you can have A without having B – Smite 29/5, 2019 at 12:32

using web2py on Google App Engine is a great strategy. It lets you get up and running fast, and if you do outgrow the restrictions of GAE then you can move your web2py application elsewhere.

However, keeping this portability means you should stay away from the advanced parts of GAE (Task Queues, Transactions, ListProperty, etc).

Snot answered 15/12, 2009 at 4:59 Comment(2)

Mind that you can use the task queue with web2py (and in fact it uses it internally to do a sort of keep-alive so that GAE caches web2py code and serves pages faster) and you can use use transactions to they extend that GAE supports it (using web2py DAL code into GAE run_in_transaction). Sometimes to use some DAL functionality you may have to use the DAL API vs the web2py API. – Kathykathye 15/12, 2009 at 18:2

Good point about Task Queue. I was thinking of my own use case where I need to postprocess uploaded files. – Snot 15/12, 2009 at 23:34

The AppEngine uses BigTable as it's datastore backend. Don't try to write a traditional relational-database driven application. BigTable is much more well suited for use as a highly-scalable key-value store. Avoid joins if at all possible.

Kneehigh answered 14/12, 2009 at 20:28 Comment(0)

I wouldn't worry about any of this. After having played with Google App Engine for a while now, I've found that it scales quite well for large data sets. If your data elements are large (i.e. photos), then you'll need to integrate with another service to handle them, but that's probably going to be true no matter what with data of that size. Also, I've found BigTable relatively easy to work with having come from a background entirely in relational databases. Finally, Django is a somewhat hidden, but awesome, "feature" of Google App Engine. If you've never used it, it's a really nice, elegant web framework that makes a lot of common tasks trivial (forms come to mind here).

Tamarind answered 15/12, 2009 at 0:48 Comment(2)

Since the OP mentioned web2py, it is quite likely that he/she already knows a lot about Django. IMO, web2py makes a lot more common tasks trivial than even Django. – Cosmic 15/12, 2009 at 9:53

@Bialecki, What about GAE's pricing? – Smite 29/5, 2019 at 12:34

Google has just released version 1.3.0 of the SDK with support with a new Blobstore API for storage of files up to 50MB. See the post "App Engine SDK 1.3.0 Released Including Support for Larger User Uploads".

Malcom answered 15/12, 2009 at 7:44 Comment(1)

web2py team is already working on supporting this out of the box and under the hood for Field(...,type='blob'). – Kathykathye 15/12, 2009 at 18:3

What about Google Wave? It's being built on appengine, and once live, real-time translatable chat reaches the corporate sector... I could see it hitting top 1000th... But then again, that's an internal project that gets to do special stuff other appengine apps can't.... Like hanging threads; I think... And whatever else Wave has under the hood...

Helles answered 3/1, 2010 at 11:57 Comment(1)

I don't think Google Wave runs on App Engine. It was written with Google Web Toolkit (GWT), though. – Cowskin 3/1, 2010 at 18:59

-11

If you are planning on a 'huge' website, then don't use App Engine. Simple as that. The App Engine is not built to deliver the next top 1000th website.

Allow me to also ask what do you mean by 'huge', how many simultaneous users? Queries per second? DB load?

Murex answered 14/12, 2009 at 19:58 Comment(4)

I'm curious what makes you say that. All of GAE is built to scale and scale and scale, at the cost of some additional complexity. The only problem I see is that with GAE's pricing model you will either pay through the nose for it, or have it exceed quotas really fast. Am I missing something? – Truscott 14/12, 2009 at 20:4

I'd like to know more as well. It doesn't seem helpful to just say App Engine is not built to deliver the next top 1000th website without saying why especially when the quantification of 'huge' is unknown. – Wale 14/12, 2009 at 20:38

App Engine is built for exactly that. – Massarelli 14/12, 2009 at 23:12

Dan, your answer is almost as vauge as the question :) How many queries per second is too much for an App Engine app? – Stroke 15/12, 2009 at 4:52

Recommended topics

Hot tags