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

在研究Google App Engine（GAE）时，很明显使用Django在GAE上使用Python进行开发非常受欢迎。 我一直在网上search，find使用Django的成本和收益的信息，找出为什么它如此受欢迎。 虽然我已经能够find关于如何在GAE上运行Django以及各种方法的各种资源，但是我还没有find任何比较分析， 说明为什么 Django更适合使用Google提供的webapp框架。

清楚的是，为什么在GAE上使用Django对于Django中的现有技能（无疑是大多数Python Web开发人员）或Django中的现有代码（使用GAE更多的是移植练习）是有用的。 然而，我的团队正在评估GAE用于一个全新的项目，我们现有的经验是TurboGears，而不是Django。

当BigTable库取代了Django的ORM时，Django为什么对开发团队有利，这是相当困难的，会话和authentication必然会改变，Django的模板（如果需要的话）可以在不使用整个Django堆栈的情况下使用。

最后，很显然，如果我们之后想要离开GAE，并且需要一个平台来针对外stream，那么使用Django确实具有提供“退出策略”的优势。

我非常感谢帮助指出为什么使用Django比在GAE上使用webapp更好。 我对Django也完全没有经验，所以在GAE上编写更小的特性和/或便利对我来说也是很有价值的。

Answer 1

我们在我们的appengine实例上使用django，大多数情况下我们必须为用户提供实际的网站。 它有一个伟大的模板引擎，URL路由和所有的内置请求/响应/error handling。所以即使我们不能使用魔术orm /pipe理的东西，它有很多去。

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

Answer 2

如果您确定GAE适合您，Django可能不是您的正确select。 这两种技术的优势并不是很吻合 – 你完全失去了Django在GAE上的绝妙ORM，如果你真的使用它，那么你写的代码并不直接适合bigtable和GAE的工作方式。

关于GAE的事情是，它强迫你编写容易从头开始扩展的代码，从而获得极大的可伸缩性。 你不能做很多不好的事情（当然，你仍然可以编写糟糕的代码，但是你可以避免一些陷阱）。 权衡是你真的最终围绕框架进行编码，如果你使用像Django这样的devise用于不同环境的东西。

如果你看到自己因为某种原因离开了GAE，那么投资基础设施就有问题了。 对bigtable进行编码意味着移植到不同的体系结构将会更加困难（尽pipeApache项目正在为您解决这个问题，使用Hadoop项目的HBase组件）。 GAE转型还有很多工作要做。

使用GAE的动力是什么，除了Google产品，还有一个很酷的stream行语？ 是否有一个原因，使用像mediatemple的产品提供的东西不太可能适合你？ 你确定GAE的尺度适合你的应用吗？ 如果您希望达到性能领域，那么与专用服务器相比，成本如何？ 与传统的负载均衡服务器设置相比，您能否使用GAE提供的工具很好地解决您的问题？

所有这一切说，除非你绝对肯定需要GAE提供的边界荒谬的扩展，否则我个人build议不要让这个特定的服务结构成为你select的框架。 我喜欢Django，所以我会说你应该使用它，但不是GAE。

编辑（2010年6月）：作为对此评论稍后的更新：Google已经宣布GAE的类似于SQL的function并不是免费的，但可以让您轻松执行诸如运行SQL样式的命令来生成关于数据的报告。

此外，即将到来的GAE查询语言的变化将允许以更容易的方式进行复杂的查询。 查看来自Google I / O 2010的video。

此外，在Code 2010 Summer项目中还有一些工作正在进行，django核心不应该支持django核心，进而使GAE的工作更容易。

作为一个主机平台，GAE变得越来越有吸引力了。

编辑（2011年8月）：

而Google只是通过改变定价结构，大幅度提高了平台的大多数用户的成本。 lockin问题已经变得更好（如果你的应用程序足够大，你可以部署apache的替代品），但是对于大多数应用程序来说，运行服务器或VPS部署更便宜。

很less有人真的有大数据问题。 “哦，我的创业公司可能会缩放一天”不是一个大数据问题。 现在build立一些东西，用标准工具把它们拿出来。

Answer 3

我在GAE上做了很多项目。 一些在Django，一些在正常的框架。

对于小事，我通常使用他们的简单和快速的正常框架。 像http : //stdicon.com，http://yaml-online-parser.appspot.com/或http://text-twist.appspot.com/ 。

对于大型的事情，我和Django一起去利用所有好的中间件和插件。 像http://metaward.com一样。;

基本上我的试金石是否会花费我2个多星期的时间写出一个真正的软件项目？ 如果是这样，与Django的插件。

它还有另外一个好处，如果你的项目不适合BigTable，那么你就快速移植（就像BigTable很慢或者我是愚蠢的）？

Answer 4

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

现在您可以使用Google Cloud SQL

Django是一个stream行的第三方Python Web框架。 与Google Cloud SQL结合使用时，App Engine上运行的应用程序可以完全支持其所有function 。 支持在Django中使用Google Cloud SQL是由定制的Django数据库后端提供的，该后端包装了Django的MySQL后端。

https://cloud.google.com/appengine/docs/python/cloud-sql/django

但请注意免责声明：

在App Engine中支持Google Cloud SQL 是实验性的 ，创新性的，并且正在迅速提高。 由于这是一项新function，因此App Engine对Cloud SQL的支持可能会根据产品需求和来自用户的反馈而发生变化

Answer 5

我有经验使用Django而不是GAE。 根据我对Django的经验，这是一个非常简单的设置，部署过程在Web项目方面非常简单。 当然，我必须学习Python，才能真正掌握一些东西，但是在一天结束的时候，我会在一个项目中再次使用它。 这是差不多两年前才达到1.0的，所以我的知识已经有些过时了。

如果你担心改变平台，那么这将是一个更好的select，我想。

Answer 6

我无法回答这个问题，但你可能想看看web2py。 它在很多方面类似于Django，但是它的数据库抽象层在GAE上工作，并支持大部分的GAEfunction（不是所有的，但我们试图追赶）。 通过这种方式，如果GAE适合您，那么您可以将代码移动到不同的数据库（SQLite，MySQL，PostgreSQL，Oracle，MSSQL，FireBird，DB2，Informix，Ingres以及 – 很快 – Sybase和MongoDB ）。

Answer 7

对于Google App引擎开发，我还是一个新手，但是Django提供的接口确实比默认的接口好得多。 好处将取决于您在应用程序引擎上运行Django的用途。 Django的Google App Engine Helper允许您使用Google App Engine的全部function以及一些Djangofunction。

Django非rel的尝试提供尽可能多的Django的权力，但运行在应用程序引擎可能的额外的可伸缩性。 特别是，它包含了Django模型（Django的核心特性之一），但由于关系数据库和bigtable之间的差异，这是一个抽象的抽象。 最有可能的是在function和效率方面进行权衡，以及错误和怪癖的数量增加。 当然，在问题描述的情况下，这可能是值得的，但除此之外，强烈build议在开始时使用助手，因为之后您可以select纯粹的应用程序引擎或不使用Django。 另外，如果你切换到Django non-rel，如果Django抽象破坏了，你对于应用引擎工作方式的更多了解将会非常有用 – 当然，如果你更换了Django的非rel，那么肯定比Django非rel的怪癖/解决方法更有用。另一种方式。

Answer 8

如果您决定在GAE之外运行您的应用程序，则仍然可以使用Django。 GAEnetworking应用程序你不会真的有那么多的运气