我正在启动新的Google App Engine应用程序，目前正在考虑两个框架：Flask和webapp2。我对以前的App Engine应用程序使用的内置webapp框架感到非常满意，因此我认为webapp2会更好，并且不会有任何问题。
但是，Flask有很多不错的评论，我真的很喜欢Flask的方法以及到目前为止我在文档中阅读的所有内容，并且我想尝试一下。但是我有点担心Flask会遇到的局限性。
因此，问题是- 你是否知道Flask可能会带入Google App Engine应用程序的任何问题，性能问题，限制（例如，路由系统，内置授权机制等）？我所说的“问题”是指我无法在几行代码（或任何合理数量的代码和工作量）中解决的问题或完全不可能的事情。
还有一个后续问题：尽管我可能会遇到任何问题，但你认为Flask中是否有任何杀手级功能可以打动我，让我使用它？
坚持使用webapp（或其自然发展版本，webapp2）的一大优势在于，你不必为自己选择的框架为现有的SDK处理程序创建自己的版本。
例如，deferred使用webapp处理程序。要在纯Flask视图中使用werkzeug.Request和werkzeug.Response来使用它，你需要为此实现deferred（就像我在这里为tipfy 所做的那样）。
其他处理程序也会发生同样的情况：blobstore（Werkzeug仍然不支持范围请求，因此即使你创建了自己的处理程序，也需要使用WebOb －请参见tipfy.appengine.blobstore），邮件，XMPP等，或将来包含在SDK中的其他内容。
对于使用App Engine创建的库，也是如此，例如ProtoRPC，它基于webapp，并且如果你不想将webapp和你的框架混合使用，则需要一个端口或适配器才能与其他框架一起使用。同一应用中的选择处理程序。
因此，即使你选择其他框架，你也将不得不结束a）在某些特殊情况下使用webapp或b）必须为特定的SDK处理程序或功能创建和维护你的版本（如果要使用它们的话）。
与WebOb相比，我更喜欢Werkzeug，但是在移植和维护可与Tipfy一起使用的SDK处理程序版本超过一年之后，我意识到这是一个失败的原因-长期支持GAE，最好是保持与webapp / WebOb。它使对SDK库的支持变得轻而易举，维护变得更加容易，并且随着新的库和SDK功能的开箱即用，它也更加面向未来，而且大型社区可以使用相同的App Engine工具来受益。
