变大 — Flask 文档

变大

以下是扩展代码库或扩展应用程序时的选项。

阅读来源。

Flask 开始部分演示如何在现有的使用良好的工具 Werkzeug（WSGI）和 Jinja（模板）之上构建您自己的框架，并且随着它的发展，它变得对广大受众有用。 随着代码库的增长，不要只使用 Flask – 理解它。 阅读源码。 Flask 的代码是为了可读而写的； 它的文档已发布，因此您可以使用其内部 API。 Flask 坚持使用上游库中记录的 API，并记录其内部实用程序，以便您可以找到项目所需的挂钩点。

钩。 延长。

API 文档充满了可用的覆盖、挂钩点和 信号 。 您可以为请求和响应对象等内容提供自定义类。 深入了解您使用的 API，并寻找在 Flask 版本中开箱即用的定制。 寻找可以将您的项目重构为一组实用程序和 Flask 扩展的方法。 探索社区中的许多 扩展 ，如果没有找到所需的工具，请寻找模式来构建自己的扩展。

子类。

Flask 类有许多为子类化而设计的方法。 您可以通过子类化 Flask（请参阅链接的方法文档）并在实例化应用程序类的任何地方使用该子类来快速添加或自定义行为。 这适用于 应用程序工厂 。 有关示例，请参阅 子类化 Flask 。

用中间件包裹。

Application Dispatching 模式详细展示了如何应用中间件。 您可以引入 WSGI 中间件来包装 Flask 实例，并在 Flask 应用程序和 HTTP 服务器之间的层引入修复和更改。 Werkzeug 包括几个 中间件 。

叉子。

如果以上选项都不起作用，请 fork Flask。 Flask 的大部分代码都在 Werkzeug 和 Jinja2 中。 这些库完成了大部分工作。 烧瓶只是将它们粘合在一起的糊状物。 对于每个项目，底层框架都有阻碍（由于原始开发人员的假设）。 这是很自然的，因为如果不是这种情况，框架将是一个非常复杂的系统，这将导致陡峭的学习曲线和很多用户的挫败感。

这不是 Flask 独有的。 许多人使用他们框架的补丁和修改版本来解决缺点。 这个想法也体现在 Flask 的 license 中。 如果您决定修改框架，则不必贡献任何更改。

分叉的缺点当然是 Flask 扩展很可能会中断，因为新框架具有不同的导入名称。 此外，集成上游更改可能是一个复杂的过程，具体取决于更改的数量。 因此，分叉应该是最后的手段。

像专业人士一样扩展。

对于许多 Web 应用程序而言，代码的复杂性与预期的用户或数据条目数量的扩展相比，并不是一个问题。 Flask 本身仅在扩展方面受到应用程序代码、要使用的数据存储以及运行的 Python 实现和 Web 服务器的限制。

例如，良好的扩展意味着如果您将服务器数量增加一倍，您将获得大约两倍的性能。 扩展性不好意味着如果您添加新服务器，应用程序的性能将不会更好，甚至不支持第二台服务器。

Flask 中的缩放只有一个限制因素，即上下文本地代理。 它们取决于在 Flask 中被定义为线程、进程或 greenlet 的上下文。 如果您的服务器使用某种不基于线程或 greenlet 的并发，Flask 将不再能够支持这些全局代理。 然而，大多数服务器使用线程、greenlet 或单独的进程来实现并发性，这些都是底层 Werkzeug 库很好支持的方法。

与社区讨论。

Flask 开发人员让具有大大小小的代码库的用户可以访问该框架。 如果您发现由 Flask 造成的障碍，请随时联系邮件列表或 Discord 服务器上的开发人员。 Flask 和 Flask 扩展开发人员改进大型应用程序工具的最佳方式是从用户那里获取反馈。