作為一名長期的 Django 開發人員，我觀察到 FastAPI 在 Python 社群中越來越受歡迎，這是有充分理由的。 FastAPI 擁有易用性、效能、簡潔的語法、透過 Pydantic 整合的 Python 型別提示、本機非同步支援以及許多其他可能讓 Django 愛好者羨慕的功能。
然而，我選擇不深入研究 FastAPI，而是選擇堅持使用 Django。以下是我個人的十個原因：
1. 無聊的技術勝過花哨的技術
雖然我承認 FastAPI 具有引人注目的功能，但我首先看重的是穩定性。 Django 是穩定性之王，多年來的破壞性變化和迴歸最小。每次更新都經過嚴格的測試，框架幾乎沒有外部依賴，從而避免了重大陷阱。
Django 經受住了時間的考驗。這是一種可靠、簡單、有效的技術。
2、資源豐富
18 年後，Django 積累了豐富的資源，其中許多資源仍然具有相關性（尤其是後端開發）並且維護良好。 Stack Overflow 上的答案在幾年後仍然有效，ChatGPT 始終根據廣泛的內容提供相關建議。
當我遇到一個獨特的問題時，可能有一個包可以解決它，或者至少有一篇詳細介紹解決方案的部落格文章。
3. 全棧或後端的靈活性
儘管 Django 具有全棧功能，但純粹將 Django 用作後端框架是完全可行的。事半功倍是可能的。誠然，由於缺乏針對性課程，從頭開始學習 Django 並僅關注後端開發可能具有挑戰性。
然而，即使對於單頁應用程式，選擇使用 Django 建立基本前端對於簡單、非面向客戶端的 CRUD 應用程式來說也是有利的，而無需動態行為。
4. ORM 首選項
在使用 Django 的 ORM 多年之後，切換到 SQLAlchemy 或任何其他 ORM 感覺不自然。這並不是對 SQLAlchemy 質量的批評，而是對適應不同系統的困難的承認。
雖然 FastAPI 提供了 ORM 替代方案，但經驗告訴我，選擇不太常見的解決方案會帶來一系列挑戰，包括減少文件和支援。
5. 非同步功能的用處有限
儘管 FastAPI 具有原生 ASGI 伺服器支援的優勢，但我質疑 Django 中非同步功能的必要性，即使可以選擇使用 Django 通道。在使用 JavaScript 的 Promise 和 async/await 後，我意識到這些功能常常使問題變得複雜，因為大多數任務不需要它們。對於真正的非同步任務，像Celery這樣的工具就足夠了，對於 websocket，可以使用Soketi server或Pusher等解決方案。
6. 誤導性的“少樣板”主張
這種批評並不是針對 FastAPI，而是針對那些用“hello world”示例過度簡化其介紹的框架。啟動專案的難易程度並不等於其隨著時間的推移的可管理性或可擴充套件性。
Django 的初始設定可能看起來很複雜，但隨著專案的擴充套件，它的結構和約定可以指導開發人員，使得初始開銷是值得的。
7. 約定的價值
Django 的約定提供了避免常見陷阱和理解最佳架構實踐的路線圖。雖然有時存在限制，但這些約定有助於開發人員之間更輕鬆地協作和決策。框架構建者比我聰明，99% 的時候，他們執行的內容會幫助我避免陷阱，同時也會教會我什麼是好的架構。
8. 效能並不是一切
儘管 Django 可能不是效能最好的框架，尤其是與 FastAPI 相比，但我發現開發技能對效能問題的影響比所用技術的固有功能更大。此外，並不是每個專案都需要極高的效能水平，對於那些需要極高效能水平的專案來說，Python 可能不是首選。
9. 對專案可持續性的擔憂
專案可持續性對單一主要維護者的依賴令人擔憂。儘管我自己使用Vue.js（同樣依賴於關鍵個人），但他們的參與可能突然停止會帶來風險。
10.考慮 TypeScript 框架
作為一名熟悉 TypeScript 和 Vue 的全棧開發人員，我發現使用AdonisJS這樣的全棧 TypeScript 框架，再加上Prisma這樣的 ORM ，對於具有簡單後端需求的專案更具吸引力。這種方法透過前端和後端的統一語言簡化了專案管理。
選擇在哪裡投入時間學習新技術是個人決定，由個人偏好、專案要求和長期目標決定。