使用Google App Engine的反馈？

希望做一个非常小的，快速的肮脏的一面项目。 我喜欢这样一个事实，即Google App Engine正在Python中运行，Django内置于其中 – 为我提供了尝试该平台的借口…但是我的问题是：

除了玩具问题之外，有没有人使用过应用引擎？ 我在那里看到一些很好的示例应用程序，所以我会认为这对于真正的交易来说已经足够了，但是想得到一些反馈。

任何其他成功/失败的说明会很好。

Answer 1

我已经尝试过我的小型地震监视应用程序http://quakewatch.appspot.com/的应用程序引擎;

我的目的是看到应用程序引擎的function，所以这里是要点：

1. 它不会默认使用django，它有自己的web框架pythonic有像Django的URL调度器，它使用Django的模板所以，如果你有Django exp。 你会发现它很容易使用
   • 但是，您可以使用任何纯粹的Python框架和django可以很容易地添加请参阅http://code.google.com/appengine/articles/django.html谷歌应用程序引擎Django的（; http://code.google.com/ p / google-app-engine-django / ）项目非常出色，几乎就像在Django项目上工作一样
2. 你不能在服务器上执行任何长时间运行的进程，你做的是回复请求，哪些应该是快速，否则appengine会杀死它所以，如果你的应用程序需要大量的后端处理appengine不是最好的方式，否则你将不得不做的处理在你自己的服务器上
3. 我的quakewatch应用程序具有订阅function，这意味着我不得不通过电子邮件发送最新的地震，但我不能在应用程序引擎中运行后台进程来监视新的地震解决scheme在这里是使用第三方服务，如pingablity.com，可以连接到您的网页之一，并执行订阅电子邮件，但在这里，你也必须小心，你不花很多时间在这里或任务分成几块
4. 它提供了类似于build模function的Django，但是后端是完全不同的，但是对于一个新的项目来说，它应该不重要。

但总的来说，我认为这是创build不需要很多后台处理的应用程序的优秀。

编辑：现在任务队列可用于运行批处理或计划任务

编辑：在GAE上工作/创build一个真正的应用程序一年后，现在我的观点是，除非你正在制作一个需要扩展到数百万用户的应用程序，否则不要使用GAE。 在GAE中维护和执行简单的任务是一个令人头痛的问题，由于分布式的性质，为了避免超时错误，计数实体或者复杂的查询需要复杂的代码，所以小复杂的应用程序应该坚持LAMP。

编辑：模型应考虑所有未来的交易而特别devise，因为只有在同一个实体组中的实体才能用于交易，并且使更新两个不同组的过程成为恶梦，例如，将货币从用户1转移到用户2在交易中是不可能的，除非它们在同一个实体组中，但是使它们成为相同的实体组可能不是最适合频繁更新的目的….阅读本文http://blog.notdot.net/2009/9/Distributed-Transactions-上应用引擎;

Answer 2

我正在使用GAE来托pipe几个高stream量的应用程序。 喜欢在50-100瑞奇/秒的数量级。 这很好，我不能推荐它。

我以前的web开发经验是用Ruby（Rails / Merb）。 学习Python很容易。 我没有混淆Django或Pylons或任何其他框架，只是从GAE的例子开始，并build立了我所需要的基本webapp库提供。

如果您习惯了SQL的灵活性，那么数据存储可能需要一些时间来适应。 没有太创伤！ 最大的调整是从联接移开。 你必须摆脱正常化至关重要的想法。

本

Answer 3

我使用Google App Engine遇到的一个令人信服的原因是与您的域名的Google Apps集成。 从本质上讲，它允许您创build自定义，受pipe理的Web应用程序，这些应用程序仅限于您的域的（受控）login。

我对这段代码的大部分经验是构build一个简单的时间/任务跟踪应用程序。 模板引擎非常简单，而且使得多页面应用程序非常易于使用。 login/用户意识api同样有用。 我能够制作一个公共页面/私人页面范例，没有太多的问题。 （用户可以login查看私人页面，匿名用户只能显示公共页面。）

当我因为“真正的工作”而离开时，我正在进入项目的数据存储部分。

我在很短的时间内完成了很多工作（现在还没有完成）。 由于我以前从来没有用过Python，所以特别愉快（因为这对我来说是一种新的语言，也因为尽pipe新语言的发展仍然很快）。 我遇到了很less的事情，导致我相信我无法完成我的任务。 相反，我对function和function有相当积极的印象。

这是我的经验。 也许它不仅仅是一个未完成的玩具项目，而且它代表了对平台的一个明智的试用，我希望这有助于。

Answer 4

“运行Django的App Engine”的想法有点误导。 App Enginereplace了整个Django模型层，因此准备花费一些时间适应App Engine的数据存储，这需要不同的build模和思考数据的方式。

Answer 5

我用GAE来build立http://www.muspy.com

这不仅仅是一个玩具项目，也不是太复杂。 我仍然要依靠几个要解决的问题，但总体来说，开发这个网站是一个愉快的经历。

如果你不想处理托pipe问题，服务器pipe理等，我可以肯定地推荐它。 特别是如果你已经知道Python和Django。

Answer 6

我认为App Engine对于小型项目来说非常酷。 有很多事情可以说，永远不必担心托pipe。 该API也推动你构build可伸缩应用程序的方向，这是一个很好的做法。

• app-engine-patch是Django和App Engine之间的一个很好的层，可以使用auth应用程序等等。
• Google已经承诺在2008年底之前实施SLA和定价模式。
• 请求必须在10秒内完成，5秒内完成需要Web服务的子请求才能完成。 这迫使您devise一个快速，轻量级的应用程序，将严重的处理卸载到其他平台（例如托pipe服务或EC2实例）。
• 更多的语言即将推出！ 谷歌不会说，虽然:-)。 我的钱接下来是Java。

Answer 7

这个问题已经得到充分的回答。 哪个好。 但有一点可能值得一提。 谷歌应用程序引擎有一个Eclipse的插件，这是一个喜悦的工作。

如果你已经用eclipse做了你的开发，那么你将会非常高兴。

要部署在谷歌应用程序引擎的网站上，我需要做的只是点击一个小button – 飞机标志 – 超。

Answer 8

看看sql游戏 ，它非常稳定，实际上是将stream量限制在一个点上，以至于它被Google限制了。 除了在其他人完全控制的服务器上托pipe您的应用以外，我什么都没有看到关于App Engine的好消息。

Answer 9

我用GAE来构build一个简单的应用程序，它接受一些参数，格式和发送电子邮件。 这是非常简单和快速。 我还在GAE数据存储和memcache服务（ http://dbaspects.blogspot.com/2010/01/memcache-vs-datastore-on-google-app.html ）上做了一些性能基准testing。 这不是那么快。 我的意见是，GAE是强制执行某些方法的严肃平台。 我认为这将演变成真正可扩展的平台，那里不好的做法是不允许的。

Answer 10

我使用GAE为我的Flash游戏网站，大胡子游戏 。 GAE是一个很棒的平台。 我使用的Django模板比以前的PHP更容易。 它有一个伟大的pipe理面板，并给你真正的日志。 数据存储与MySQL之类的数据库不同，但使用起来要容易得多。 build设网站很容易，直接，他们有很多有用的build议在网站上。

Answer 11

我用GAE和Django来构build一个Facebook应用程序。 我用http://code.google.com/p/app-engine-patch作为起点，因为它有Django 1.1的支持。 我没有尝试使用任何manage.py命令，因为我认为他们不会工作，但我甚至没有看到它。 该应用程序有三个模型，也使用pyfacebook，但这是复杂程度。 我正在build立一个更复杂的应用程序，我开始在http://brianyamabe.com上发表博客。;