歷史、設計與未來¶

這個專案的歷史是什麼？它似乎在幾週內就從默默無聞變得非常出色 [...]

以下是這段歷史的簡述。

替代方案¶

我多年來一直在開發具有複雜需求的 API（機器學習、分散式系統、非同步作業、NoSQL 資料庫等），並領導數個開發團隊。

作為其中一部分，我需要研究、測試和使用許多替代方案。

FastAPI 的歷史很大程度上就是其前身們的歷史。

如果沒有前人的工作，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 的未來一片光明。

您的協助將不勝感激您的協助。