作为一名长期的 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 ，对于具有简单后端需求的项目更具吸引力。这种方法通过前端和后端的统一语言简化了项目管理。
选择在哪里投入时间学习新技术是个人决定，由个人偏好、项目要求和长期目标决定。