1
DeWjjj 279 天前
fastapi 不也有 drf 一样的 api 页面么,这俩没什么差别主要是 django 之前不支持 async ,现在不是也可以 async 了。
所以,除了 django 比较重之外没啥别的问题。 |
2
lambdaq 279 天前 3
还以为有什么长篇大论详细说明好在什么地方呢。。。结果。。。。
|
3
summerwar 279 天前 1
fastapi 的优势在于跟他的名字一样,写 API 比较快,然后连文档直接都可以搞定,侧重点不同。
建议两个都搭建起来体验下,立马就懂了 |
4
chenqh 279 天前
因为 django 要学的东西比 fastapi 多,入门比轻型框架难, 就这样..没有什么其他原因.
|
5
albert0yyyy 279 天前
只写过 drf 和 ninja ,现在好像 ninja 给官方收纳了,我用的 ninja 刚出来,我觉得写起来是真的方便真的快。就 drf 输入输出校验就要写好大一串。
|
6
Rebely 279 天前
drf 和 Django 现有生态结合的好,orm ,filters ,form ,权限 等。缺点就是学习成本稍高,包括 view set 和 mixins 这种类视图,对新手有点不好理解, 不像其他两个看点示例就能用的七七八八。
再有就是 drf 的 serializer 对比起 pydantic 是真的难用啊, 还不止是一点半点。 赶紧参考 pydantic 这种设计 replace 了吧 |
7
LeeReamond 279 天前 1
1. 因为 Django 几个版本迭代后的不兼容更新多,维护体验是狗屎。
2. 因为 drf 笨重的生态中的很多实现不是最佳实践。在大多数时候如果我不愿意背着大量我不需要的功能走,那我愿意做那个重新发明轮子的啥 B ,我的轮子比你的圆,我乐意你管得着么。 |
8
Vegetable 279 天前 1
因为真的两个都用过很多,知道基于 FastAPI 的项目更容易写出易于长期维护的代码
|
9
acerphoenix 279 天前
drf 帮开发者实现的东西太多了. 增加很多学习成本, 不是我不想学, 而是我都有个实现的认知和方法, 再让我换一套, 尤其团队, 生产环境, 挺困难的
|
10
kuituosi 279 天前
因为 python 的框架是典型的重复造轮子
毕竟 python 开发太简单了,不造轮子不舒服斯基 |
11
moonriver00 278 天前
django 限制太多了,其他的灵活的多
|
12
yph007595 277 天前
@albert0yyyy #5 被官方收纳是啥意思
|
13
metavoidx 269 天前
DRF 的 serializers 确实不好用,太啰嗦了,明明 Python 有类型注解的标准,还方便 IDE 提示和补全
FastAPI 我也用过,写接口方便些,但是太薄了,我还是比较喜欢 Django 的模型层和 QuerySet 所以我自己写了一个后端元框架 [UtilMeta]( https://github.com/utilmeta/utilmeta-py),用 Python 标准的类型声明来处理接口请求和 CRUD ,可以支持 Django 模型接入(后续也考虑其他的 ORM 框架像 SQLAchemy ),也支持其他的框架作为运行时实现,比如 Flask, Sanic, FastAPI |
14
metavoidx 269 天前
@metavoidx 看来 v2 的评论并不支持 markdown 也没法编辑,Github 链接在 https://github.com/utilmeta/utilmeta-py
|
15
huangzhiyia 237 天前
|
16
shujuliuer 172 天前 via iPhone
10 年后端开发经验的人都不愿多碰 drf ,写法啰嗦臃肿,文档不友好。反观 ninja ,文档精致到相关代码行高亮,各种加粗和’ 标识,看起来很舒服又贴心。少有的让我一口气翻一遍的文档。推荐一个中文版的。https://django-ninja.cn/
|
17
yuan321 OP @shujuliuer 但是 drf ,写那种简单的增删改查确实还是很方便的
|
18
shujuliuer 119 天前
@yuan321 说的没错,但是现在 django-ninja 也有 crud 包了。感觉比 drf 要简单很多。 https://django-ninja.cn/django-ninja-crud/guides/01-Introduction/
|