python - Google App Engine 的 Flask 与 webapp2

Question

我正在启动新的 Google App Engine 应用程序，目前正在考虑两个框架:Flask和 webapp2 .我对我以前的 App Engine 应用程序使用的内置 webapp 框架相当满意，所以我认为 webapp2 会更好，我不会有任何问题。

但是，有很多对 Flask 的好评，我真的很喜欢它的方法以及到目前为止我在文档中阅读的所有内容，我想尝试一下。但我有点担心我在使用 Flask 时可能面临的限制。

所以，问题是 - 您知道 Flask 可能给 Google App Engine 应用程序带来的任何问题、性能问题、限制(例如路由系统、内置授权机制等)吗？ “问题”是指我无法通过几行代码(或任何合理数量的代码和努力)解决的问题或完全不可能的问题。

作为后续问题:Flask 中是否有任何 killer 级功能，您认为可以让我大吃一惊并让我使用它，尽管我可能会遇到任何问题？

Answer 1

免责声明:我是tipfy和webapp2的作者。

坚持使用 webapp(或其自然演变，webapp2)的一大优势是，您不必为您选择的框架为现有 SDK 处理程序创建自己的版本。

例如，deferred使用 webapp 处理程序。要在纯 Flask View 中使用它，使用 werkzeug.Request 和 werkzeug.Response，您需要为它实现 deferred(就像我为 tipfy 做的 here)。

其他处理程序也会发生同样的情况:blobstore(Werkzeug 仍然不支持范围请求，因此即使您创建自己的处理程序，您也需要使用 WebOb ——请参阅 tipfy.appengine.blobstore)、邮件、XMPP 等，或将来包含在 SDK 中的其他内容。

使用 App Engine 创建的库也是如此，例如 ProtoRPC ，它基于 webapp，如果您不想在同一个应用中混合使用 webapp 和 your-framework-of-choice 处理程序，则需要端口或适配器才能与其他框架一起使用。

因此，即使您选择不同的框架，您也将结束 a) 在某些特殊情况下使用 webapp 或 b) 必须为特定的 SDK 处理程序或功能创建和维护您的版本(如果您将使用它们)。

我更喜欢 Werkzeug 而不是 WebOb，但是在移植和维护原生与 tipfy 一起工作的 SDK 处理程序版本一年多之后，我意识到这是一个失败的原因——要长期支持 GAE，最好是靠近 webapp/WebOb。它使对 SDK 库的支持变得轻而易举，维护变得更加容易，它更具前瞻性，因为新库和 SDK 功能将开箱即用，并且有一个大型社区围绕相同的 App Engine 工具工作的好处。

总结了一个具体的webapp2防御here .添加到那些 webapp2 can be used outside of App Engine并且是 easy to be customized to look like popular micro-frameworks你有很多令人信服的理由去做。此外，webapp2 很有可能被包含在未来的 SDK 版本中(这是非官方的，不要引用我的话 :-) 这将插入它向前发展并带来新的开发人员和贡献。

也就是说，我是 Werkzeug 和 Pocoo 家伙的忠实粉丝，我从 Flask 和其他人(web.py、Tornado)那里借了很多东西，但是 - 而且，你知道，我有偏见 - 以上应考虑 webapp2 的好处。