历史、设计与未来¶

这个项目的历史是什么？它似乎在几周内就从默默无闻变得非常强大 [...]

以下是关于这段历史的简述。

替代方案¶

多年来，我一直致力于创建具有复杂需求（机器学习、分布式系统、异步作业、NoSQL 数据库等）的 API，并领导过多个开发团队。

在此过程中，我需要调研、测试并使用许多替代方案。

FastAPI 的历史在很大程度上是其前身的历史。

正如替代方案一节中所述

如果没有前人的工作，FastAPI 就不会存在。

在此之前，已经有许多工具的诞生为它的创建提供了灵感。

几年来我一直避免创建新的框架。起初，我尝试使用许多不同的框架、插件和工具来解决 FastAPI 所涵盖的所有功能。

但在某个阶段，唯一的办法就是创建一个能够提供所有这些功能的工具，吸取先前工具的最佳理念，以尽可能最好的方式将它们结合起来，并利用以前甚至不可用的语言特性（Python 3.6+ 类型提示）。

调研¶

通过使用所有先前的替代方案，我有机会向它们学习，汲取灵感，并为自己以及我合作过的开发团队找到我能想到的最佳组合方式。

例如，很明显，它理想情况下应该基于标准的 Python 类型提示。

此外，最好的方法是使用现有的标准。

因此，在开始编写 FastAPI 之前，我花了好几个月的时间研究 OpenAPI、JSON Schema、OAuth2 等规范，了解它们之间的关系、重叠部分和差异。

设计¶

然后，我花了一些时间设计我作为用户（使用 FastAPI 的开发者）所期望的开发者“API”。

我在最流行的 Python 编辑器中测试了几个想法：PyCharm、VS Code、基于 Jedi 的编辑器。

根据最近的 Python 开发者调查，这些涵盖了大约 80% 的用户。

这意味着 FastAPI 是专门针对 80% 的 Python 开发者使用的编辑器进行测试的。而且由于大多数其他编辑器的运行方式相似，它的所有优势应该几乎适用于所有编辑器。

通过这种方式，我可以找到尽可能减少代码重复、实现全局自动补全、类型检查和错误检查等的最佳方法。

这一切都是为了给所有开发者提供最佳的开发体验。

需求¶

在测试了几个替代方案后，我决定使用 Pydantic，因为它具有诸多优势。

之后，我为其做出了贡献，使其完全符合 JSON Schema，支持多种方式定义约束声明，并基于在多个编辑器中的测试改进了编辑器支持（类型检查、自动补全）。

在开发过程中，我还为另一个关键需求 Starlette 做了贡献，它是 FastAPI 的另一个核心支柱。

开发¶

当我开始创建 FastAPI 本身时，大部分组件都已经到位，设计已经明确，需求和工具也已准备就绪，对于标准和规范的知识也清晰且掌握得当。

未来¶

到目前为止，很明显 FastAPI 及其理念对许多人来说是非常有用的。

因为它能更好地适应许多用例，所以人们开始选择它，而不是之前的替代方案。

许多开发者和团队已经在他们的项目中依赖 FastAPI（包括我和我的团队）。

但是，未来仍有许多改进和功能有待实现。

FastAPI 前途无量。

同时也非常感谢您的帮助。