django 快速开发明明 drf 更好，为啥还是很多人更推荐 fast.api 和忍者

fastapi 不也有 drf 一样的 api 页面么，这俩没什么差别主要是 django 之前不支持 async ，现在不是也可以 async 了。
所以，除了 django 比较重之外没啥别的问题。

还以为有什么长篇大论详细说明好在什么地方呢。。。结果。。。。

fastapi 的优势在于跟他的名字一样，写 API 比较快，然后连文档直接都可以搞定，侧重点不同。

建议两个都搭建起来体验下，立马就懂了

因为 django 要学的东西比 fastapi 多,入门比轻型框架难, 就这样..没有什么其他原因.

只写过 drf 和 ninja ，现在好像 ninja 给官方收纳了，我用的 ninja 刚出来，我觉得写起来是真的方便真的快。就 drf 输入输出校验就要写好大一串。

drf 和 Django 现有生态结合的好，orm ，filters ，form ，权限 等。缺点就是学习成本稍高，包括 view set 和 mixins 这种类视图，对新手有点不好理解， 不像其他两个看点示例就能用的七七八八。

再有就是 drf 的 serializer 对比起 pydantic 是真的难用啊， 还不止是一点半点。 赶紧参考 pydantic 这种设计 replace 了吧

1. 因为 Django 几个版本迭代后的不兼容更新多，维护体验是狗屎。
2. 因为 drf 笨重的生态中的很多实现不是最佳实践。在大多数时候如果我不愿意背着大量我不需要的功能走，那我愿意做那个重新发明轮子的啥 B ，我的轮子比你的圆，我乐意你管得着么。

因为真的两个都用过很多，知道基于 FastAPI 的项目更容易写出易于长期维护的代码

drf 帮开发者实现的东西太多了. 增加很多学习成本, 不是我不想学, 而是我都有个实现的认知和方法, 再让我换一套, 尤其团队, 生产环境, 挺困难的

因为 python 的框架是典型的重复造轮子
毕竟 python 开发太简单了，不造轮子不舒服斯基

django 限制太多了，其他的灵活的多

@albert0yyyy #5 被官方收纳是啥意思

DRF 的 serializers 确实不好用，太啰嗦了，明明 Python 有类型注解的标准，还方便 IDE 提示和补全
FastAPI 我也用过，写接口方便些，但是太薄了，我还是比较喜欢 Django 的模型层和 QuerySet
所以我自己写了一个后端元框架 [UtilMeta]( https://github.com/utilmeta/utilmeta-py)，用 Python 标准的类型声明来处理接口请求和 CRUD ，可以支持 Django 模型接入（后续也考虑其他的 ORM 框架像 SQLAchemy ），也支持其他的框架作为运行时实现，比如 Flask, Sanic, FastAPI

@metavoidx 看来 v2 的评论并不支持 markdown 也没法编辑，Github 链接在 https://github.com/utilmeta/utilmeta-py

drf 写法太啰嗦了，之前每新建一个 Model 我都要分别打开三个文件，serializers 下的 x.py, models 目录下的 x.py, apis 目录下的 x.py, 写的时候 ide 提示很恼火，需要自己手动翻来翻去。

现在我把 serializer model api 统统直接写在 apis 目录下的 x.py 上了，啥时候代码复杂影响了阅读了再拆分。

10 年后端开发经验的人都不愿多碰 drf ，写法啰嗦臃肿，文档不友好。反观 ninja ，文档精致到相关代码行高亮，各种加粗和’ 标识，看起来很舒服又贴心。少有的让我一口气翻一遍的文档。推荐一个中文版的。https://django-ninja.cn/

@shujuliuer 但是 drf ，写那种简单的增删改查确实还是很方便的

@yuan321 说的没错，但是现在 django-ninja 也有 crud 包了。感觉比 drf 要简单很多。 https://django-ninja.cn/django-ninja-crud/guides/01-Introduction/