为什么要在 Google App Engine 上使用 Django?

在研究 Google App Engine (GAE)时,很明显,在 GAE 上用 Python 开发 Django 非常流行。我一直在网上寻找使用 Django 的成本和收益的信息,发现 为什么非常流行。虽然我已经能够在 怎么做上找到各种各样的资源来在 GAE 上运行 Django 以及各种各样的方法,但是我还没有发现任何关于 为什么 Django 的比较分析比使用 Google 提供的 webapp 框架更好。

需要明确的是,为什么在 GAE 上使用 Django 对于拥有 Django 中现有技能的开发人员(毫无疑问,大多数 Python web 开发人员)或者在 Django 中拥有现有代码的开发人员(在 Django 中使用 GAE 更像是一种移植练习)是有用的,这一点很明显。然而,我的团队正在评估 GAE 在一个全新的项目中的使用,我们现有的经验是使用 TurboGears,而不是 Django。

当 BigTable 库已经取代了 Django 的 ORM,会话和身份验证都必须更改,而且 Django 的模板(如果需要的话)不需要使用整个 Django 堆栈就可以使用时,很难确定为什么 Django 对开发团队是有益的。

最后,很明显,如果我们以后想要离开 GAE,并且需要一个平台来实现大批离开,那么使用 Django 确实具有提供“退出策略”的优势。

我将非常感谢帮助指出使用 Django 的 为什么比在 GAE 上使用 webapp 更好。我对 Django 也完全没有经验,所以详细阐述在 GAE 上工作的较小特性和/或便利性对我来说也很有价值。

25155 次浏览

I have experience using Django and not GAE. From my experiences with Django it was a very simplistic setup and the deployment process was incredibly easy in terms of web projects. Granted I had to learn Python to really get a good hold on things, but at the end of the day I would use it again on a project. This was almost 2 years ago before it reached 1.0 so I my knowledge is a bit outdated.

If you are worried about changing platforms, then this would be a better choice I suppose.

Django probably isn't the right choice for you, if you're sure that GAE is right for you. The strengths of the two technologies don't align very well - you completely lose a lot of Django's wonderful orm on GAE, and if you do use it, you write code that isn't really directly suitable to bigtable and the way GAE works.

The thing about GAE is that it gets the great scalability by forcing you to write code that scales easily from the ground up. You just can't do a number of things that scale poorly (of course, you can still write poorly scaling code, but you avoid some pitfalls). The tradeoff is that you really end up coding around the framework, if you use something like Django which is designed for a different environment.

If you see yourself ever leaving GAE for any reason, becoming invested in the infrastructure there is a problem for you. Coding for bigtable means that it will be harder to move to a different architecture (though the apache project is working to solve this for you with the HBase component of the Hadoop project). It would still be a lot of work to transition off of GAE.

What's the driving motivator behind using GAE, besides being a Google product, and a cool buzzword? Is there a reason that scaling using something like mediatemple's offering is unlikely to work well for you? Are you sure that the ways that GAE scales are right for your application? How does the cost compare to dedicated servers, if you're expecting to get to that performance realm? Can you solve your problem well using the tools GAE provides, as compared to a more traditional load-balanced server setup?

All this said, unless you absolutely positively need the borderline-ridiculous scaling that GAE offers, I'd personally suggest not letting that particular service structure your choice of framework. I like Django, so I'd say you should use it, but not on GAE.

Edit (June 2010): As an update to this comment sometime later: Google has announced sql-like capabilitys for GAE that aren't free, but will let you easily do things like run SQL-style commands to generate reports on your data.

Additionally, there are upcoming changes to the GAE query language which will allow complex queries in a far easier fashion. Look at the videos from Google I/O 2010.

Furthermore, there is work being done during the Summer of Code 2010 project which should bring no-sql support to django core, and by extension, make working with GAE significantly easier.

GAE is becoming more attractive as a hosting platform.

Edit (August 2011):

And Google just raised the cost to most users of the platform significantly by changing the pricing structure. The lockin problem has gotten better (if your application is big enough you can deploy the apache alternatives), but for most applications, running servers or VPS deployments is cheaper.

Very few people really have bigdata problems. "Oh my startup might scale someday" isn't a bigdata problem. Build stuff now and get it out the door using the standard tools.

I've done lots of projects on GAE. Some in django, some in their normal framework.

For small things, I usually use their normal framework for simplicity and quickness. Like http://stdicon.com, http://yaml-online-parser.appspot.com/, or http://text-twist.appspot.com/.

For large things, I go with django to take advantage of all the nice middleware and plugins. Like http://metaward.com.

Basically my litmus test is Will this take me more than 2 weeks to write and be a REAL software project? If so, go with django for the addons.

It has the added benefit of, if your project is badly suited for BigTable then you quickly port off (like I did Is BigTable slow or am I dumb?)

I cannot answer the question but you may want to look into web2py. It is similar to Django in many respects but its database abstraction layer works on GAE and supports most of the GAE functionality (not all but we try to catch up). In this way if GAE works for you great, if it does not, you can move your code to a different db (SQLite, MySQL, PostgreSQL, Oracle, MSSQL, FireBird, DB2, Informix, Ingres, and - soon - Sybase and MongoDB).

We use django on our appengine instances mostly when we have to serve actual websites to the user. It has a great template engine, url routing and all the request/response/error handling built in. So even while we can't use the magic orm/admin stuff it has a lot going for it.

For api services we built something very simple on top of webob. It's far more lightweight because it doesn't need everything that django offers, and therefore a little quicker in some situations.

If you decide to run you app outside of GAE, you can still use Django. You won't really have that much luck with the GAE webapp

I am still very new to Google App engine development, but the interfaces Django provides do appear much nicer than the default. The benefits will depend on what you are using to run Django on the app engine. The Google App Engine Helper for Django allows you to use the full power of the Google App Engine with some Django functionality on the side.

Django non-rel attempts to provide as much of Django's power as possible, but running on the app-engine for possible extra scalability. In particular, it includes Django models (one of Django's core features), but this is a leaky abstraction due to the differences between relational databases and bigtable. There will most likely be tradeoffs in functionality and efficiency, as well as an increased number of bugs and quirks. Of course, this might be worth it in circumstances like those described in the question, but otherwise would strongly recommend using the helper at the start as then you have the option of moving towards either pure app-engine or Django non-rel later. Also, if you do switch to Django non-rel, your increased knowledge of how app engine works will be useful if the Django abstraction ever breaks - certainly much more useful than knowledge of the quirks/workarounds for Django non-rel if you swap the other way.

I think all this answers are a bit obsolete.

Now you can use Google Cloud SQL

Django is a popular third-party Python web framework. When coupled with Google Cloud SQL, all of its functionality can be fully supported by applications running on App Engine. Support for using Google Cloud SQL with Django is provided by a custom Django database backend which wraps Django's MySQL backend.

https://cloud.google.com/python/django/appengine

one more fresh news is, that there is BETA support for PostgreSQL