燒瓶死了嗎？ FastAPI 是未來嗎？

在我的相關搜尋中，我注意到即使到了 2024 年，仍有相當多的人推薦 Flask 作為 Python Web 框架。不過，在我看來，「Flask 正在走向淘汰，FastAPI 代表著未來」。這就是我寫這篇文章的原因。歡迎大家參與討論，提出反駁。

Flask 與 FastAPI

Flask 在 Python 開發者心中佔有重要地位。如果您是 Web 開發人員，我敢打賭您很可能使用過 Flask，但也許您從未涉足過 FastAPI。

這裡有兩個證據：

1. 在近一兩年新出現的與Web開發相關的Python新專案中​​，幾乎所有涉及Web開發的專案都採用了FastAPI。
2. 截至2024年12月25日，在GitHub上，FastAPI的star數（78.9k）已超過Flask（68.4k）。

現在我們來看看官方Python開發者調查中Web框架佔比的變化。

很明顯，2019 年 FastAPI 甚至沒有被列為選項，但到 2023 年，其份額已達到 25%。 （目前，我們只有 2023 年之前的數據。）

要注意的是，這個比例資料涵蓋了現有系統，因此Django和Flask的比例不會快速下降。儘管如此，趨勢還是很明顯的。

我們都知道，Web 框架領域非常豐富，幾乎每年都會出現新的框架。這些框架大多數都是短暫的，但也有一些能夠持久存在。 FastAPI誕生於2018年底，2019年底左右開始嶄露頭角。那麼，它如何在短短五年內超越2010年底誕生的Flask呢？接下來，讓我們沿著時間軸追溯Python Web框架和相關解決方案的發展歷史，以便更好地理解。

Web 框架（外掛程式、工具）的演變

FastAPI的作者是一位極為關注Python生態發展的開發者。擴展閱讀連結2是作者寫的《Alternatives, Inspiration and Comparisons》（https://fastapi.tiangolo.com/alternatives/），詳細闡述了FastAPI從各個庫中汲取的參考或啟發。本文的發展歷史部分也參考了這篇文章。我建議閱讀原文，因為它包含了FastAPI出現的原理以及作者的一些設計理念。

燒瓶

Flask 是一個「微型」框架，與 Django 有著天壤之別。它只保留了少數核心功能，為了解耦，將其他功能拆分成幾個函式庫（例如 Jinja2、Werkzeug 等）。這給了開發者足夠的自由，使他們能夠毫不費力地為相關功能編寫第三方外掛程式。它的內部設計，如藍圖、上下文和用於表示路線、信號等的裝飾器，在當時是相當先進的。再加上全面的文檔，它對新手來說非常友好。

Flask REST 框架

由於其簡單性，Flask 非常適合建立 API。然而，由於Flask本身沒有任何內建功能，因此我們需要專門的REST框架。於是，flask-restful、Flask-RESTPlus、flask-api等框架相繼出現。此外，在 REST 服務中，存在資料驗證、解析和規範的需求，這導致了 Marshmallow、Webargs 和 APISpec 的出現，直到 Flask-apispec 出現。然而，在整個開發過程中，與 DRF 相媲美的 Flask REST 框架從未實現。

現階段，Flask的缺點逐漸凸顯出來。

Flask 最初的優勢在於其靈活性和極簡性，但這也意味著需要內部開發大量組件。這要么需要一家擁有專門開發人員進行開發和維護的大公司，要么需要非常有能力的個人開發人員。否則，插件很難達到生產質量，導致 Flask 第三方插件魚龍混雜，無法保證長期維護。如前所述，其中許多庫已經停止維護。

所以，即使在今天，如果你想用 Flask 建立一個 API 服務，你仍然需要拼湊各種元件。對於一些沒有及時更新的組件，需要您自行排查。老手也許能夠應付，但對於初學者來說，這相當令人畏懼，尤其是當他們想要應用最新的實踐和概念時。

Asyncio 生態系統

從Python 3.5開始，asyncio已經成為未來的趨勢。於是，出現了一些原生支援 asyncio 的 Web 框架，例如 aiohttp、Starlette、sanic。

這時候，Flask 就不太適應了。社區添加對 asyncio 的支持進展緩慢，Flask 的原作者已經轉而編寫 Rust，將項目留給了兩名維護者（現在只剩下一名維護者）。

apistar、melt等建置API服務的專案都為FastAPI的誕生提供了設計靈感。

快速API

然後，FastAPI 誕生了。作者原本是在尋求一個好的解決方案，但上述情況各有各的問題或限制。於是，作者創造了這個新的框架。

為什麼 FastAPI 脫穎而出

這是文章的核心部分。以下原因正是FastAPI能夠取代Flask的原因。

使用 Pydantic 驗證用戶數據

API開發過程中，資料格式驗證、解析、序列化是常規操作。多年來，出現了多種解決方案，目前 Pydantic 是首選：

乍一看，這段程式碼看起來像是ORM或資料類別的編寫方式，但實際上，它使用Python原生的Type Hints語法來註解欄位類型。例如，在上面的範例中，/items/請求中的Item的schema已經被明確定義，每個欄位的值類型都是明確的。相較於舊有的使用 schema 描述甚至硬編碼的方式，這種方式更加簡潔，更符合 Python 風格，並且有更好的 IDE 支援。

目前，Pydantic 在用戶資料驗證領域佔據主導地位。由於 FastAPI 內建了它，因此大大簡化了驗證過程，並減少了錯誤。這就是為什麼FastAPI官網提到解決方案可以減少開發者高達40%的錯誤。對於像Python這樣的動態語言，如果不使用mypy進行類型檢查，應用Pydantic是必不可少的。

此外，由於 Pydantic 的集成，向專案添加 ORM（例如 SQLAlchemy）變得非常容易。從請求中獲得的物件可以直接傳遞到資料庫，因為資料驗證已經完成。反之亦然，從資料庫檢索到的物件也可以直接回傳。

相較之下，Flask 在這方面有所欠缺。

非同步設計

Flask 時代，程式碼執行是單執行緒、同步的。這意味著必須逐一處理請求，而其他請求會在前一個請求完成之前浪費時間等待 I/O 操作。另一方面，Asyncio 是最佳解決方案。它可以使 I/O 操作非同步，讓您無需等待任務完成即可取得任務結果，然後繼續處理其他任務請求。

FastAPI 原生支援並發和非同步程式碼。只要程式碼寫得正確，就可以達到最高效率。因此，它被認為是目前最快的Python框架，其效率與NodeJS或Go類似。當速度和效能至關重要時，FastAPI 無疑是最佳選擇。

對 ASGI 的本機支持

我們先提一下WSGI。它的全名為“Python Web Server Gateway Interface”，可參考“PEP 3333”（https://peps.python.org/pep-3333/）。它是專門為 Web 應用程式和伺服器之間的互動編寫的 Python 標準。如果您使用過 PHP 或 Ruby，您可能會發現它更容易理解。 Flask 依賴 Werkzeug，它是一個 WSGI 套件，因此 Flask 支援這個舊的 WSGI 標準，而不是 ASGI。

WSGI 的問題在於它無法利用非同步來提高效能和效率。所以，Django通道開創了ASGI。它的全名是“非同步伺服器網關介面”，這是一個迭代的、幾乎完全重新設計的標準。它提供非同步伺服器/應用程式介面並支援 HTTP、HTTP/2 和 WebSocket。與 WSGI 不同，ASGI 允許每個應用程式有多個非同步事件。此外，ASGI 支援同步和非同步應用程式。您可以將舊的同步 WSGI Web 應用程式移轉到 ASGI，也可以使用 ASGI 建立新的非同步 Web 應用程式。

在下結論之前，我們先補充五個術語解釋：

1. ASGI Toolkit：實作ASGI相關功能的函式庫（如URL路由、Request/Response物件、模板引擎等）。本文主要指的是Starlette，它對應的是Flask的依賴Werkzeug。
2. ASGI Web 框架：實作 ASGI 規範的 Web 框架（如 FastAPI），而 Flask 和 Django 是實作 WSGI 的 Web 框架。這些框架專為開發人員編寫應用程式而設計，具有易於使用的介面。開發者只需要根據自己的需求填寫業務邏輯。早期的框架大多在內部實現ASGI工具包，而後來的框架通常會結合合適的工具包。例如，Flask 使用 Werkzeug（自己的），FastAPI 使用 Starlette（其他人的）。
3. Web應用程式：使用Web框架創建的應用程式就是Web應用程式。通常，Web 框架附帶一個測試伺服器，可以啟動該伺服器進行開發和調試。如果你不關心效能和穩定性的話，你已經可以在瀏覽器中存取開發地址來存取這個應用程式了。
4. Web 伺服器：現實世界比想像的更複雜。 Web應用部署到生產環境後，需要考慮請求負載平衡、靜態檔案服務、存取控制、反向代理程式等需求，同時對效能也有很高的要求。 Web框架內建的Web伺服器根本無法滿足這些要求，因此需要專門的Web伺服器。目前Nginx是主流選擇。
5. ASGI 伺服器：ASGI 伺服器可作為 Web 伺服器和 Web 應用程式之間的橋樑。 ASGI伺服器也遵循ASGI規範，但其主要任務是滿足轉送請求的效能要求，因此它主要照顧ASGI的「G」（網關）部分。其程式碼對於開發者編寫Web應用業務和路由邏輯並不友善。目前，最知名的ASGI伺服器是Uvicorn，原本來自WSGI伺服器Gunicorn的uvicorn.workers.UvicornWorker也是一個選擇。這些是生產環境中的建議用法。

以前WSGI的生產環境解決方案通常是Nginx Gunicorn Flask(Django)，而現在ASGI的生產環境解決方案是Nginx Uvicorn FastAPI。

還有一件事。從FastAPI的名稱和介紹來看，很明顯地它是為了建構API服務而設計的。其實它的核心程式碼就是這樣的。可以說，它不是一個傳統的、完全自行實現的框架，而更多的是一個結合了各種框架優點的框架。它從一個空殼開始，組裝必要且合適的組件。例如，它沒有模板引擎。如果你確實需要用它來建立需要模板渲染的網路應用程序，你可以選擇並組合你需要的模板引擎。當然，你也可以使用Starlette內建的Jinja2（是的，Flask也內建了）。

為什麼 Flask 已死

上述FastAPI的優點並不足以斷定Flask已死。那麼，我為什麼要持有這樣的觀點呢？主要取決於開發者和使用者的受歡迎程度。

這裡的「受歡迎程度」是相當主觀的。我能想到的指標如下：

1. 社區活動(https://github.com/pallets/flask/issues)：以專案的 issues 和 pull requests 數量為例。 Flask 只有個位數，這與 FastAPI 完全不同。這其實從側面反映出該項目已經不再活躍了。如果專案活躍的話，老用戶會有更多的需求。如果他們停止提出問題，就意味著他們已經離開了。而新用戶肯定會遇到各種各樣的問題。即使有詳細的文檔，仍然應該有很多用戶來提問和貢獻程式碼。沒有這種情況表示使用者較少。
2. 討論熱度：即部落格文章、Stack Overflow 等網站上的查詢和討論的熱度。很明顯，現在寫 Flask 的人很少了。
3. 開發迭代頻率(https://github.com/pallets/flask/pulls)：從commit記錄可以看出，Flask只有一名維護者，偶爾修復一些bug，沒有什麼主要功能發展。
4. 關鍵人物的影響力：Flask背後的關鍵人物，專案發起人，早已不再參與此專案。根據專案貢獻記錄，Armin Ronacher 上次為該開發做出貢獻是在六年前。

在我看來，所有這些情況都表明 Flask 的鼎盛時期已經過去，FastAPI 是後起之秀。

最後介紹一下部署Flask/FastAPI的理想平台：Leapcell。

Leapcell是專為現代分散式應用程式設計的雲端運算平台。其按需付費的定價模式確保沒有閒置成本，這意味著用戶只需為他們實際使用的資源付費。

Leapcell對於WSGI/ASGI應用的獨特優點：

1. 多語言支持

• 支援 JavaScript、Python、Go 或 Rust 開發。

2. 無限項目免費部署

• 僅依使用情況收費。沒有要求時不收費。

3. 無與倫比的成本效益

• 即用即付，無閒置費用。
• 例如，25 美元可以支援 694 萬個請求，平均回應時間為 60 毫秒。

4.簡化的開發者體驗

• 直覺的使用者介面，易於設定。
• 完全自動化的 CI/CD 管道和 GitOps 整合。
• 即時指標和日誌，提供可操作的見解。

5. 輕鬆的可擴充性和高效能

• 自動伸縮，輕鬆應付高併發。
• 零營運開銷，讓開發者專注於開發。

在文件中了解更多！

Leapcell Twitter：https://x.com/LeapcellHQ

以上是燒瓶死了嗎？ FastAPI 是未來嗎？的詳細內容。更多資訊請關注PHP中文網其他相關文章！