历史、设计与未来¶

这个项目的历史是怎样的？它似乎短短几周内就从默默无闻变得如此出色 [...]

以下是一些相关历史。

替代方案¶

多年来我一直为复杂需求构建 API（机器学习、分布式系统、异步任务、NoSQL 数据库等），并领导多个开发团队。

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

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 拥有光明的未来。

我们非常期待您的参与支持。