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

在研究Google App Engine（GAE）时，很明显，使用Django在基于GAE的Python中进行开发非常流行。我一直在网上搜索有关使用Django的成本和收益的信息，以了解为什么它如此受欢迎。虽然我已经找到了许多有关如何在GAE 上运行Django的资料以及各种实现方法，但是我还没有找到任何比较分析来说明为什么 Django比使用Google提供的webapp框架更可取。

显而易见，对于在Django中具有现有技能的开发人员（毫无疑问是大多数Python网络开发人员）或在Django中具有现有代码的开发人员（在其中使用GAE更像是移植练习），为什么在GAE上使用Django很有用。但是，我的团队正在评估GAE是否可用于全新项目，而我们现有的经验是使用TurboGears，而不是Django。

当BigTable库已替换Django的ORM，会话和身份验证已更改且Django的模板（如果需要）而无需使用整个Django堆栈时，很难确定Django为什么对开发团队有利。

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

我会非常感谢您指出为什么在GAE上使用Django比使用webapp更好的方法。我也对Django完全没有经验，因此详细介绍适用于GAE的较小功能和/或便利性对我来说也很有价值。

我们主要在必须向用户提供实际网站的情况下，在我们的appengine实例上使用django。它具有出色的模板引擎，URL路由和内置的所有请求/响应/错误处理。因此，即使我们不能使用神奇的orm / admin东西，它也有很多用处。

对于api服务，我们在之上构建了一些非常简单的东西webob。它轻巧得多，因为它不需要django提供的所有功能，因此在某些情况下要快一些。

如果您确定GAE适合您，那么Django可能不是您的正确选择。两种技术的优势无法很好地融合在一起-您完全失去了许多Django在GAE上的奇妙功能，如果您使用它，您编写的代码实际上并不真正适合bigtable和GAE的工作方式。

关于GAE的事情是，通过强迫您编写从头开始轻松扩展的代码，它具有出色的可伸缩性。您只是不能做很多伸缩性差的事情（当然，您仍然可以编写伸缩性差的代码，但要避免一些陷阱）。折衷方案是，如果您使用为其他环境设计的类似Django之类的东西，则最终最终围绕框架进行编码。

如果您发现自己出于任何原因离开GAE，而对基础设施进行投资，那对您来说就是一个问题。为bigtable编码意味着将很难迁移到其他架构（尽管apache项目正在努力通过Hadoop项目的HBase组件为您解决此问题）。过渡到GAE仍然需要大量工作。

除了成为Google产品和一个时髦的流行词之外，使用GAE的背后推动因素是什么？是否有理由使用mediatemple的产品进行扩展对您不太可能有效？您确定GAE扩展方式适合您的应用程序吗？如果您希望达到该性能领域，那么与专用服务器相比，成本如何？与更传统的负载平衡服务器设置相比，使用GAE提供的工具能否很好地解决您的问题？

综上所述，除非您绝对肯定需要GAE提供的边界可笑的扩展，否则我个人建议不要让该特定服务构成您选择的框架。我喜欢Django，所以我想您应该使用它，但不要在GAE上使用它。

编辑（2010年6月）： 在一段时间后对此评论进行了更新：Google宣布了针对GAE的类似于SQL的功能，该功能不是免费的，但可以让您轻松地执行诸如运行SQL风格的命令来生成数据报告之类的操作。

此外，GAE查询语言即将进行更改，这将允许以简单得多的方式进行复杂的查询。观看来自Google I / O 2010的视频。

此外，在代码2010年夏季项目中正在进行一些工作，这些工作应该为django核心带来no-sql支持，并且通过扩展，使使用GAE的工作变得更加容易。

GAE作为托管平台正变得越来越有吸引力。

编辑（2011年8月）：

Google刚刚通过更改定价结构，大大提高了该平台大多数用户的成本。锁定问题已经变得更好（如果您的应用程序足够大，则可以部署apache替代方案），但是对于大多数应用程序而言，运行服务器或VPS部署会更便宜。

很少有人真正遇到大数据问题。“哦，我的创业公司有一天可以扩展”不是大数据问题。现在构建东西，并使用标准工具将其发布。

我在GAE上做了很多项目。有些在Django中，有些在其正常框架中。

对于小事情，我通常使用它们的常规框架来简化和快捷。就像http : //stdicon.com，http://yaml-online-parser.appspot.com/或http://text-twist.appspot.com/一样。

对于大型事情，我选择django来利用所有出色的中间件和插件。就像http://metaward.com一样。

基本上我的试金石是，这将使我花费超过2个星期的时间来编写并成为一个REAL软件项目吗？如果是这样，请与Django一起使用。

它具有额外的好处，如果您的项目非常不适合BigTable，则您会迅速移植（就像我做了BigTable慢还是我笨吗？）

我认为所有这些答案都已过时。

现在您可以使用 Google Cloud SQL

Django是一种流行的第三方Python Web框架。与Google Cloud SQL结合使用时，在App Engine上运行的应用程序可以完全支持其所有功能。自定义Django数据库后端提供了对将Google Cloud SQL与Django一起使用的支持，该后端包装了Django的MySQL后端。

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

还有一个新鲜的消息是，BETA支持PostgreSQL

我有使用Django而不是GAE的经验。从我使用Django的经验来看，这是一个非常简单的设置，并且就Web项目而言，部署过程非常简单。当然，我必须学习Python才能真正掌握事物，但最终我还是会在项目中再次使用它。这是将近2年前才达到1.0的水平，所以我的知识有点过时了。

如果您担心更改平台，那么我认为这将是一个更好的选择。

我无法回答这个问题，但您可能想研究一下web2py。它在许多方面与Django类似，但其数据库抽象层在GAE上运行并支持大多数GAE功能（不是所有，但我们都在努力追赶）。这样，如果GAE为您工作得很好，或者不是，您可以将代码移动到其他数据库（SQLite，MySQL，PostgreSQL，Oracle，MSSQL，FireBird，DB2，Informix，Ingres，以及-很快-Sybase和MongoDB ）。

如果您决定在GAE之外运行您的应用，则仍然可以使用Django。GAE网络应用真的不会给您那么多运气

我对Google App引擎的开发仍然很陌生，但是Django提供的接口确实比默认接口好得多。收益将取决于您在应用程序引擎上运行Django所使用的内容。Django的Google App Engine帮助器允许您一边使用Django的某些功能，一边使用Google App Engine的全部功能。

Django non-rel尝试提供尽可能多的Django功能，但在应用程序引擎上运行以实现可能的额外可伸缩性。特别是，它包括Django模型（Django的核心功能之一），但是由于关系数据库和bigtable之间的差异，这是一个泄漏的抽象。在功能和效率方面，很可能需要权衡取舍，并且错误和怪癖的数量也会增加。当然，在类似问题中所述的情况下，这样做可能是值得的，但是强烈建议在开始时使用帮助程序，因为这样您以后可以选择使用纯应用程序引擎或不依赖Django的选项。另外，如果您确实切换到Django non-rel，