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

时间:2009-12-20 05:03:45

标签: python django google-app-engine

在研究Google App Engine(GAE)时,很明显使用Django在GAE上用Python开发非常受欢迎。我一直在网上搜索有关使用Django的成本和好处的信息,找出为什么它如此受欢迎。虽然我已经能够在如何上找到关于在GAE上运行Django的各种方法以及这样做的各种方法,但我还没有找到关于为什么的比较分析 Django比使用Google提供的webapp框架更可取。

很明显,很明显为什么在DjE上使用Django对于Django(大多数Python Web开发人员,毫无疑问)具有现有技能的开发人员或Django中的现有代码(使用GAE更多是移植)行使)。然而,我的团队正在评估GAE用于一个全新的项目,我们现有的经验是TurboGears,而不是Django。

当BigTable库替换了Django的ORM时,确定Django对开发团队有益的原因非常困难,会话和身份验证必然会发生变化,并且Django的模板(如果需要)可以在不使用整个Django堆栈的情况下使用。 / p>

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

我非常感谢帮助指出为什么使用Django比在GAE上使用webapp更好。我对Django也缺乏经验,所以对GAE的小功能和/或便利性的详细说明对我来说也很有价值。

8 个答案:

答案 0 :(得分:50)

如果您确定GAE适合您,那么Django可能不适合您。这两种技术的优势并不是很好 - 你在GAE上完全失去了很多Django的精彩内容,如果你使用它,你编写的代码实际上并不适合bigtable和GAE的工作方式。

关于GAE的事情是它通过强迫您编写可以从头开始轻松扩展的代码来获得极大的可伸缩性。你不能做一些规模很小的事情(当然,你仍然可以编写糟糕的缩放代码,但你可以避免一些陷阱)。如果您使用专为不同环境设计的Django之类的东西,那么权衡就是你真的最终围绕框架进行编码。

如果您发现自己因任何原因离开了GAE,那么投资基础设施就会出现问题。对bigtable进行编码意味着迁移到不同的体系结构将更加困难(尽管apache项目正在努力使用Hadoop项目的HBase组件为您解决这个问题)。从GAE过渡仍然需要做很多工作。

使用GAE背后的动力是什么,除了作为谷歌产品,还有一个很酷的流行语?是否有理由使用mediatemple的产品进行缩放不太适合您?您确定GAE扩展的方式适合您的应用吗?如果您希望达到性能领域,那么成本与专用服务器相比如何?与更传统的负载均衡服务器设置相比,您能否使用GAE提供的工具很好地解决您的问题?

所有这些都说,除非你绝对肯定需要GAE提供的边界 - 荒谬的扩展,否则我个人建议不要让这个特定的服务结构成为你选择的框架。我喜欢Django,所以我会说你应该使用它,但不能使用GAE。

编辑(2010年6月): 稍后作为此评论的更新: 谷歌已经宣布了GAE的类似SQL的功能,这些功能不是免费的,但可以让你轻松地执行诸如运行SQL风格的命令来生成数据报告。

此外,GAE查询语言即将发生变化,这将允许以更容易的方式进行复杂查询。观看Google I / O 2010中的视频。

此外,在2010年夏季代码项目期间正在进行的工作应该为django核心带来无sql支持,并且通过扩展,使得与GAE的合作变得更加容易。

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

编辑(2011年8月):

谷歌通过改变定价结构,大大提高了该平台大多数用户的成本。锁定问题变得更好(如果您的应用程序足够大,您可以部署apache备选方案),但对于大多数应用程序,运行服务器或VPS部署更便宜。

很少有人真的有大数据问题。 “哦,我的创业公司可能有一天会扩展”并不是一个大数据问题。立即构建内容并使用标准工具将其推出门外。

答案 1 :(得分:19)

我们在appengine实例上使用django,主要是因为我们必须向用户提供实际网站。它有一个很棒的模板引擎,url路由和内置的所有请求/响应/错误处理。所以即使我们不能使用魔法orm / admin的东西,它也有很多用途。

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

答案 2 :(得分:16)

我在GAE上做了很多项目。 django中的一些,有些处于正常框架中。

对于小东西,我通常使用他们的常规框架来简化和快速。与http://stdicon.comhttp://yaml-online-parser.appspot.com/http://text-twist.appspot.com/一样。

对于大型事物,我使用django来利用所有漂亮的中间件和插件。像http://metaward.com一样。

基本上我的石蕊测试是这需要我超过2周的时间来编写并成为 REAL 软件项目吗?如果是这样,请使用django作为插件。< / p>

如果您的项目非常适合BigTable,那么它还有一个额外的好处,那么您可以快速移除(就像我做Is BigTable slow or am I dumb?

答案 3 :(得分:11)

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

现在您可以使用Google Cloud SQL

  

Django是一个流行的第三方Python Web框架。 当耦合时   使用Google Cloud SQL,可以完全支持其所有功能   在App Engine上运行的应用程序。支持使用Google Cloud   带Django的SQL由自定义Django数据库后端提供   包装Django的MySQL后端。

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

另一个新消息是,对于PostgreSQL有BETA支持

答案 4 :(得分:3)

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

如果你担心改变平台,那么我认为这是一个更好的选择。

答案 5 :(得分:0)

我无法回答这个问题,但您可能需要查看web2py。它在许多方面类似于Django,但它的数据库抽象层适用于GAE并支持大多数GAE功能(并非所有功能,但我们都试图赶上)。通过这种方式,如果GAE对您有用,如果没有,您可以将代码移动到不同的数据库(SQLite,MySQL,PostgreSQL,Oracle,MSSQL,FireBird,DB2,Informix,Ingres,以及 - 很快 - Sybase和MongoDB )。

答案 6 :(得分:0)

如果您决定在GAE之外运行app,您仍然可以使用Django。 GAE webapp

你真的没那么幸运

答案 7 :(得分:0)

我仍然是Google App引擎开发的新手,但Django提供的界面看起来确实比默认界面好得多。好处将取决于您在应用程序引擎上运行Django的用途。 Django的Google App Engine Helper允许您使用Google App Engine的全部功能和侧面的一些Django功能。

Django非rel尝试尽可能多地提供Django的功能,但是在app-engine上运行以获得额外的可扩展性。特别是,它包括Django模型(Django的核心功能之一),但由于关系数据库和bigtable之间的差异,这是一个漏洞抽象。最有可能在功能和效率方面进行权衡,以及增加错误和怪癖的数量。当然,在问题中描述的情况下这可能是值得的,但是否则会强烈建议在开始时使用帮助程序,因为您可以选择在以后转向纯app-engine或Django non-rel。此外,如果你切换到Django non-rel,那么如果Django抽象有所破坏,你对app引擎如何工作的了解将会更有用 - 当然,如果你交换了Django非rel的怪癖/变通方法的知识,那么这些知识会更有用。其他方式。