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

[yuan321]

[DeWjjj]

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

[lambdaq]

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

[summerwar]

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

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

[chenqh]

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

[albert0yyyy]

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

[Rebely]

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

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

[LeeReamond]

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

[Vegetable]

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

[acerphoenix]

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

[kuituosi]

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

[moonriver00]

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

[yph007595]

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

[metavoidx]

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

[metavoidx]

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

[zmaplex]

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

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