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

Question

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

90

在研究Google应用引擎（GAE）时，很明显使用Django开发Python应用程序在GAE上非常受欢迎。我一直在网上搜索有关使用Django的成本和收益的信息，以找出为什么它如此流行。虽然我能够找到许多关于如何在GAE上运行Django以及各种方法的来源，但我没有找到任何关于为什么Django比使用Google提供的webapp框架更可取的比较分析。

需要明确的是，对于已经具备Django技能集（毫无疑问，大多数Python web开发人员）或已经存在Django代码（在这种情况下使用GAE更像是一个移植练习）的开发人员来说，使用Django在GAE上非常有用。然而，我的团队正在评估GAE是否适用于全新项目，我们现有的经验是TurboGears，而不是Django。

确定Django对开发团队有何好处是相当困难的，因为BigTable库替换了Django的ORM，会话和身份验证必须更改，如果需要Django的模板，则可以在不使用整个Django栈的情况下获得。

最后，使用Django的优势在于，在以后想要移出GAE并需要面向大量用户的平台时，它提供了一个“退出策略”。

如果能指出为什么使用Django比在GAE上使用webapp更好，我将不胜感激。我对Django完全没有经验，因此对于在GAE上可行的较小功能和/或便利性的详细说明对我非常有价值。

- Travis Bradshaw

天啊，Terry Bradshaw 会写代码？ - Woot4Moo

4

Django很有好处，因为它很棒。就是这样简单。 :) - jathanism

我也是新手谷歌应用引擎，即使在2018年这也是一个非常好的问题（尽管现在似乎Django ORM得到了更好的GAE支持）。 :) - Divij Sehgal

8个回答

20

当我们需要向用户提供实际网站时，主要在我们的应用程序引擎实例上使用 Django。它拥有出色的模板引擎、URL 路由和所有请求/响应/错误处理功能。因此，即使我们无法使用其魔术 orm/admin 等功能，它仍然有许多优点。

对于 API 服务，我们使用了一个简单的基于 webob 的工具。它更加轻量级，因为它不需要 Django 提供的所有功能，所以在某些情况下会更快。

- Koen Bok

1

感谢Koen。我对Django吸引力的困惑之一源于这样一个想法：url路由、请求/响应/错误处理也是提供的webapp的特性，并且模板引擎也可以在不使用Django的情况下与webapp一起使用。我错了吗？Django是否比webapp框架更好地提供了这些服务？ - Travis Bradshaw

我认为在 Django 中它们更加广泛和灵活。因此，如果您确实需要它们，那么使用 Django 更好 :-) - Koen Bok

2

我认为这就是我正在寻找的答案！Django 在很大程度上与 webapp 重复，但在它们共享的功能中，Django 以更灵活和强大的方式实现。这似乎肯定是一个“边际上”的决定，但我认为所有其他建议加上你的建议会得出一个有说服力的答案。谢谢。 - Travis Bradshaw

1

不支持用C语言编写的Python模块。 - Ryu_hayabusa

16

我在 GAE 上做了很多项目，有些是 django 框架，有些是使用它们的普通框架。

对于小的事情，我通常使用他们的普通框架，以简单和快速为主要考虑因素。例如 http://stdicon.com，http://yaml-online-parser.appspot.com/ 或者 http://text-twist.appspot.com/。

对于大型项目，我选择django框架，以利用所有的中间件和插件。例如 http://metaward.com。

基本上，我的试金石是“这个项目需要我超过两周才能编写并成为一个真正的软件项目吗？”如果是这样，我会使用 django 框架来添加插件。

如果你的项目不适合 BigTable，那么这样做的额外好处是你可以很快地迁移（就像我在这里做的一样）。

- Paul Tarjan

+1，Bigtable 对于某些项目和查询来说并不是很好。它非常适合 Google 所做的事情，但可能对你想做的事情非常糟糕。 - Paul McMillan

谢谢Paul！您能否给我提供一些说明Django中间件和插件如何在GAE上运行的资源链接吗？如果有对我们项目有用的附加组件，那么选择Django而不是webapp肯定是一个理由。像会话和身份验证这样更明显有用的插件似乎具有清晰的Django ORM依赖关系。 - Travis Bradshaw

2

基本上，任何没有 models.py 的插件都可以完美工作。如果它们有 models.py，您可能可以进行 1 对 1 的转换到 Bigtable 并仍然使用它（如果您想的话）。我使用的一些插件包括 django_annoying、django_debug_toolbar，以及来自 contrib 部分的 csrf、humanize 和当然还有 admin。 - Paul Tarjan

11

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

现在你可以使用 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。

- andilabs

3

我有使用Django的经验，但没有使用GAE。从我的Django经验来看，它是一种非常简单的设置，并且在Web项目方面，部署过程非常容易。当然，我必须学习Python才能真正掌握它，但归根结底，我会再次在项目中使用它。这是将近两年前，在它达到1.0版本之前，所以我的知识有点过时。

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

- Woot4Moo

1

感谢您的快速回复！虽然我同意Django是一个快速入门的框架，但这对我们来说并不是真正的问题。我们有四名经验丰富的Python开发人员，具备Web开发背景，因此使用任何框架都将快速而轻松。但问题仍然存在，当在Django和GAE上的webapp之间进行选择时，哪个是更好的选择，为什么？ - Travis Bradshaw

@Woot4Moo 如果没有GAE的经验，你会把它部署到哪里？我对GAE还很陌生，但价格让我感到困惑，有时会出现随机的巨额费用。我在考虑使用PythonAnywhere，你能给我一些建议吗？ - Manza

0

我无法回答这个问题，但你可能想了解一下web2py。它在许多方面类似于Django，但其数据库抽象层适用于GAE并支持大多数GAE功能（不是全部，但我们正在努力追赶）。这样，如果GAE适合您，那就太好了；如果不适合，您可以将代码移动到其他数据库（SQLite、MySQL、PostgreSQL、Oracle、MSSQL、FireBird、DB2、Informix、Ingres，以及 - 不久的将来 - Sybase和MongoDB）。

- mdipierro

0

如果你决定在GAE之外运行你的应用程序，你仍然可以使用Django。但是在GAE webapp上可能不会有太多的好运。

- George Godik

谢谢，虽然我在原问题中已经明确提到了这一点：“最后，很明显使用Django的优势在于，如果我们以后想要从GAE移开并需要一个可供迁移的平台，那么Django就是一个出路。” - Travis Bradshaw

0

我对Google App引擎开发还非常新手，但Django提供的接口似乎比默认的更好。这些优点将取决于您在应用程序引擎上运行Django所使用的内容。Google App Engine Helper for Django允许您在侧面使用一些Django功能的同时，使用Google App引擎的全部功能。

Django non-rel试图尽可能提供与Django相同的强大功能，但在应用程序引擎上运行以实现额外的可扩展性。特别是它包括Django模型（Django的核心功能之一），但由于关系数据库和bigtable之间的差异，这是一个有缺陷的抽象。在功能和效率方面，很可能会有一些权衡，以及增加的错误和怪癖。当然，在像问题描述中描述的情况下，这可能是值得的，但否则强烈建议在开始时使用helper，因为这样您就可以选择向纯应用程序引擎或Django non-rel移动。此外，如果您切换到Django non-rel，则了解应用程序引擎的工作原理将非常有用，如果Django抽象出现问题，这肯定比了解Django non-rel的怪癖/解决方法更有用。

- Casebash

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Paul McMillan · Accepted Answer

如果你确定GAE适合你，那么Django可能不是正确的选择。这两种技术的优势并不非常契合 - 在GAE上，你完全失去了许多Django精美的ORM，如果你确实使用它，你编写的代码并不是真正适合bigtable和GAE的工作方式。

关于GAE的事情是，它通过强制您从头开始编写易于扩展的代码来获得出色的可扩展性。您只是不能做一些规模效果差的事情（当然，您仍然可以编写规模效果差的代码，但您需要避免一些陷阱）。权衡的是，如果您使用像Django这样设计用于不同环境的东西，那么您最终确实要在框架周围编码。

如果您有任何理由离开GAE的计划，那么为其基础设施编程是一个问题。为bigtable编程意味着将更难移动到不同的架构中（尽管Apache项目正在通过Hadoop项目的HBase组件来解决这个问题）。从GAE过渡仍然需要大量的工作。

除了是谷歌产品和很酷的流行语之外，使用GAE的驱动因素是什么？如果您希望达到那个性能级别，那么使用mediatemple之类的东西进行扩展是否行得通？您确定GAE扩展的方式适合您的应用程序吗？如果您期望达到那个性能级别，成本与专用服务器相比如何？与传统的负载均衡服务器设置相比，使用GAE提供的工具可以很好地解决您的问题吗？

所有这些都说过了，除非你真的需要GAE提供的边界荒谬的扩展，否则我个人建议不要让该特定服务结构化您的框架选择。我喜欢Django，所以我会建议您使用它，但不是在GAE上。

编辑（2010年6月）：作为对此评论的更新： Google宣布了GAE的类似SQL的功能，这些功能并不免费，但将让您轻松地执行类似于SQL的命令以生成有关数据的报告。

此外，GAE查询语言即将进行改变，这将使复杂查询更加容易。请查看Google I/O 2010的视频。

此外，在2010年的Summer of Code 项目中正在进行工作，这将为django核心带来no-sql支持，并进一步使与GAE的工作变得更加容易。

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

编辑（2011年8月）:

而且，Google通过改变定价结构使大多数用户的成本大幅提高。锁定问题已经得到改善（如果您的应用程序足够大，则可以部署Apache替代品），但对于大多数应用程序来说，运行服务器或VPS部署更便宜。

很少有人真正面临大数据问题。 "哦，我的创业公司可能会扩展"不是一个大数据问题。使用标准工具立即构建并发布。