期待做一个非常小的，快速的'脏方项目 . 我喜欢这样一个事实：Google App Engine在Python上运行，内置了Django - 给了我一个尝试该平台的借口......但我的问题是：
有没有人使用app引擎来解决玩具问题以外的问题？我看到一些很好的示例应用程序，所以我认为这对于真正的交易来说已经足够好了，但是想得到一些反馈 .
任何其他成功/失败的说明都会很棒 .
我为我的小型地震监视应用程序尝试了应用程序引擎http://quakewatch.appspot.com/
我的目的是看到应用引擎的功能，所以这里有一些要点：
它没有默认使用django，它有自己的web框架，pythonic有像django这样的URL调度程序，它使用django模板所以如果你有django exp . 你会发现它很容易使用
但你可以使用任何纯python框架和django可以轻松添加请参阅http://code.google.com/appengine/articles/django.html google-app-engine-django（http://code.google.com/p/google-app-engine-django/）项目非常好，工作几乎就像在django项目上工作
你不能在服务器上执行任何长时间运行的进程，你要做的就是回复请求，哪些应该快，否则appengine会杀掉它所以如果你的应用程序需要大量的后端处理appengine不是最好的方法，否则你将不得不这样做在您自己的服务器上处理
我的quakewatch应用程序有一个订阅功能，这意味着我必须通过电子邮件发送最新的地震，但我不能在应用程序引擎中运行后台进程来监控新的地震解决方案这里是使用像pingablity.com这样的第三方服务可以连接到您的某个页面并执行订阅电子邮件，但是在这里您还必须注意不要在这里花太多时间或将任务分成几个部分
它提供了Django之类的建模功能，但后端完全不同，但对于一个新项目来说，它应该无关紧要 .
但总的来说，我认为它非常适合创建不需要大量后台处理的应用程序 .
编辑：现在task queues可用于运行批处理或计划任务
编辑：在GAE上工作/创建一个真实的应用程序一年后，现在我的意见是，除非您正在制作一个需要扩展到百万和百万用户的应用程序，否则不要使用GAE . 在GAE中维护和执行琐碎任务是一个令人头疼的问题，由于分布式性质，避免截止日期超出错误，计算实体或执行复杂查询需要复杂的代码，因此小型复杂的应用程序应该坚持LAMP .
编辑：模型应该考虑到您将来希望拥有的所有交易而专门设计，因为只有同一实体组中的实体可以在交易中使用，并且它使更新两个不同组的过程成为噩梦，例如在交易中将资金从user1转移到user2是不可能的，除非它们在同一个实体组中，但是使它们成为相同的实体组可能不是最好的频繁更新目的....阅读本http://blog.notdot.net/2009/9/Distributed-Transactions-on-App-Engine
我使用GAE来托管几个高流量的应用程序 . 就像50-100 req / sec的订单 . 很棒，我不能推荐它 .
我之前的Web开发经验是使用Ruby（Rails / Merb） . 学习Python很容易 . 我没有弄乱Django或Pylons或任何其他框架，只是从GAE示例开始，并根据提供的基本webapp库构建了我需要的东西 .
如果您已经习惯了SQL的灵活性，那么数据存储可能需要一些时间来习惯 . 没什么太痛苦的！最大的调整是离开JOIN . 你必须认识到规范化至关重要 .
本
我使用Google App Engine遇到的一个令人信服的原因是它与您的域的Google Apps集成 . 从本质上讲，它允许您创建仅限于域（控制）登录的自定义托管Web应用程序 .
我使用此代码的大部分经验是构建一个简单的时间/任务跟踪应用程序 . 模板引擎很简单，但使得多页面应用程序非常平易近人 . 登录/用户意识api同样有用 . 我能够制作一个公共页面/私人页面范例而没有太多问题 . （用户将登录以查看私人页面 . 匿名用户仅显示公共页面 . ）
当我因为“实际工作”被拉开时，我刚刚进入项目的数据存储区 .
我以前可以在很短的时间内完成了许多工作（目前还没有完成） . 由于我之前从未使用过Python，这一点特别令人愉快（因为它对我来说是一种新语言，而且因为尽管使用了新语言，开发仍然很快） . 我遇到的很少，这使我相信我无法完成任务 . 相反，我对功能和功能有相当积极的印象 .
这是我的经验 . 也许它并不仅仅代表一个未完成的玩具项目，但它确实代表了对该平台的知情试验，我希望这有所帮助 .
“App Engine运行Django”的想法有点误导 . App Engine取代了整个Django模型层，因此准备花一些时间适应App Engine的数据存储，这需要不同的建模和思考数据的方式 .
我使用GAE来构建http://www.muspy.com
它不仅仅是一个玩具项目，也不是过于复杂 . 我仍然依赖谷歌要解决的一些问题，但整体开发网站是一种愉快的体验 .
如果您不想处理托管问题，服务器管理等，我绝对可以推荐它 . 特别是如果你已经知道Python和Django了 .
我认为App Engine在这一点上对于小型项目来说非常酷 . 因为永远不必担心托管，所以有很多话要说 . API还推动您构建可扩展应用程序，这是一种很好的做法 .
app-engine-patch是Django和App Engine之间的一个很好的层，可以使用auth app等等 .
谷歌承诺在2008年底之前提供SLA和定价模式 .
请求必须在10秒内完成，对Web服务的子请求需要在5秒内完成 . 这迫使您设计一个快速，轻量级的应用程序，将严重的处理卸载到其他平台（例如托管服务或EC2实例） .
即将推出更多语言版本！谷歌接下来在Java上赢了't say which though :-). My money' .
这个问题已得到充分回答 . 这很好 . 但有一件事值得一提 . 谷歌应用程序引擎有一个日食ide插件，这是一个愉快的工作 .
如果您已经使用eclipse进行开发，那么您将会非常高兴 .
要在谷歌应用引擎的网站上部署，我需要做的就是点击一个小按钮 - 带有飞机徽标 - 超级 .
看一下sql game，它非常稳定，实际上在一点上推动了流量限制，以便它受到谷歌的限制 . 除了在其他人完全控制的服务器上托管你的应用程序之外，我没有看到关于App Engine的好消息 .
我使用GAE构建了一个简单的应用程序，它接受一些参数，格式和发送电子邮件 . 它非常简单快速 . 我还在GAE数据存储和内存缓存服务（http://dbaspects.blogspot.com/2010/01/memcache-vs-datastore-on-google-app.html）上做了一些性能基准测试 . 它不是那么快 . 我的观点是，GAE是一个强制执行某种方法论的平台 . 我认为它将演变为真正可扩展的平台，其中不允许使用不良做法 .
我在我的flash游戏网站上使用了GAE，Bearded Games . GAE是一个很好的平台 . 我使用了Django模板，它比PHP的旧时代容易得多 . 它配备了一个出色的管理面板，为您提供了非常好的日志 . 数据存储区与MySQL之类的数据库不同，但它更容易使用 . Build 网站简单明了，他们在网站上提供了许多有用的建议 .
我用GAE和Django构建了一个Facebook应用程序 . 我使用http://code.google.com/p/app-engine-patch作为我的起点，因为它支持Django 1.1 . 我没有工作，但我没有 Build 一个更复杂的应用程序，我开始在_2445679上发表博客 .
11 回答
我为我的小型地震监视应用程序尝试了应用程序引擎http://quakewatch.appspot.com/
我的目的是看到应用引擎的功能，所以这里有一些要点：
它没有默认使用django，它有自己的web框架，pythonic有像django这样的URL调度程序，它使用django模板所以如果你有django exp . 你会发现它很容易使用
但你可以使用任何纯python框架和django可以轻松添加请参阅http://code.google.com/appengine/articles/django.html google-app-engine-django（http://code.google.com/p/google-app-engine-django/）项目非常好，工作几乎就像在django项目上工作
你不能在服务器上执行任何长时间运行的进程，你要做的就是回复请求，哪些应该快，否则appengine会杀掉它所以如果你的应用程序需要大量的后端处理appengine不是最好的方法，否则你将不得不这样做在您自己的服务器上处理
我的quakewatch应用程序有一个订阅功能，这意味着我必须通过电子邮件发送最新的地震，但我不能在应用程序引擎中运行后台进程来监控新的地震解决方案这里是使用像pingablity.com这样的第三方服务可以连接到您的某个页面并执行订阅电子邮件，但是在这里您还必须注意不要在这里花太多时间或将任务分成几个部分
它提供了Django之类的建模功能，但后端完全不同，但对于一个新项目来说，它应该无关紧要 .
但总的来说，我认为它非常适合创建不需要大量后台处理的应用程序 .
编辑：现在task queues可用于运行批处理或计划任务
编辑：在GAE上工作/创建一个真实的应用程序一年后，现在我的意见是，除非您正在制作一个需要扩展到百万和百万用户的应用程序，否则不要使用GAE . 在GAE中维护和执行琐碎任务是一个令人头疼的问题，由于分布式性质，避免截止日期超出错误，计算实体或执行复杂查询需要复杂的代码，因此小型复杂的应用程序应该坚持LAMP .
编辑：模型应该考虑到您将来希望拥有的所有交易而专门设计，因为只有同一实体组中的实体可以在交易中使用，并且它使更新两个不同组的过程成为噩梦，例如在交易中将资金从user1转移到user2是不可能的，除非它们在同一个实体组中，但是使它们成为相同的实体组可能不是最好的频繁更新目的....阅读本http://blog.notdot.net/2009/9/Distributed-Transactions-on-App-Engine
我使用GAE来托管几个高流量的应用程序 . 就像50-100 req / sec的订单 . 很棒，我不能推荐它 .
我之前的Web开发经验是使用Ruby（Rails / Merb） . 学习Python很容易 . 我没有弄乱Django或Pylons或任何其他框架，只是从GAE示例开始，并根据提供的基本webapp库构建了我需要的东西 .
如果您已经习惯了SQL的灵活性，那么数据存储可能需要一些时间来习惯 . 没什么太痛苦的！最大的调整是离开JOIN . 你必须认识到规范化至关重要 .
本
我使用Google App Engine遇到的一个令人信服的原因是它与您的域的Google Apps集成 . 从本质上讲，它允许您创建仅限于域（控制）登录的自定义托管Web应用程序 .
我使用此代码的大部分经验是构建一个简单的时间/任务跟踪应用程序 . 模板引擎很简单，但使得多页面应用程序非常平易近人 . 登录/用户意识api同样有用 . 我能够制作一个公共页面/私人页面范例而没有太多问题 . （用户将登录以查看私人页面 . 匿名用户仅显示公共页面 . ）
当我因为“实际工作”被拉开时，我刚刚进入项目的数据存储区 .
我以前可以在很短的时间内完成了许多工作（目前还没有完成） . 由于我之前从未使用过Python，这一点特别令人愉快（因为它对我来说是一种新语言，而且因为尽管使用了新语言，开发仍然很快） . 我遇到的很少，这使我相信我无法完成任务 . 相反，我对功能和功能有相当积极的印象 .
这是我的经验 . 也许它并不仅仅代表一个未完成的玩具项目，但它确实代表了对该平台的知情试验，我希望这有所帮助 .
“App Engine运行Django”的想法有点误导 . App Engine取代了整个Django模型层，因此准备花一些时间适应App Engine的数据存储，这需要不同的建模和思考数据的方式 .
我使用GAE来构建http://www.muspy.com
它不仅仅是一个玩具项目，也不是过于复杂 . 我仍然依赖谷歌要解决的一些问题，但整体开发网站是一种愉快的体验 .
如果您不想处理托管问题，服务器管理等，我绝对可以推荐它 . 特别是如果你已经知道Python和Django了 .
我认为App Engine在这一点上对于小型项目来说非常酷 . 因为永远不必担心托管，所以有很多话要说 . API还推动您构建可扩展应用程序，这是一种很好的做法 .
app-engine-patch是Django和App Engine之间的一个很好的层，可以使用auth app等等 .
谷歌承诺在2008年底之前提供SLA和定价模式 .
请求必须在10秒内完成，对Web服务的子请求需要在5秒内完成 . 这迫使您设计一个快速，轻量级的应用程序，将严重的处理卸载到其他平台（例如托管服务或EC2实例） .
即将推出更多语言版本！谷歌接下来在Java上赢了't say which though :-). My money' .
这个问题已得到充分回答 . 这很好 . 但有一件事值得一提 . 谷歌应用程序引擎有一个日食ide插件，这是一个愉快的工作 .
如果您已经使用eclipse进行开发，那么您将会非常高兴 .
要在谷歌应用引擎的网站上部署，我需要做的就是点击一个小按钮 - 带有飞机徽标 - 超级 .
看一下sql game，它非常稳定，实际上在一点上推动了流量限制，以便它受到谷歌的限制 . 除了在其他人完全控制的服务器上托管你的应用程序之外，我没有看到关于App Engine的好消息 .
我使用GAE构建了一个简单的应用程序，它接受一些参数，格式和发送电子邮件 . 它非常简单快速 . 我还在GAE数据存储和内存缓存服务（http://dbaspects.blogspot.com/2010/01/memcache-vs-datastore-on-google-app.html）上做了一些性能基准测试 . 它不是那么快 . 我的观点是，GAE是一个强制执行某种方法论的平台 . 我认为它将演变为真正可扩展的平台，其中不允许使用不良做法 .
我在我的flash游戏网站上使用了GAE，Bearded Games . GAE是一个很好的平台 . 我使用了Django模板，它比PHP的旧时代容易得多 . 它配备了一个出色的管理面板，为您提供了非常好的日志 . 数据存储区与MySQL之类的数据库不同，但它更容易使用 . Build 网站简单明了，他们在网站上提供了许多有用的建议 .
我用GAE和Django构建了一个Facebook应用程序 . 我使用http://code.google.com/p/app-engine-patch作为我的起点，因为它支持Django 1.1 . 我没有工作，但我没有 Build 一个更复杂的应用程序，我开始在_2445679上发表博客 .