FastAPI 玩腻了，全异步、注解式、支持 OpenAPI、带参数验证的框架还有啥，不限语言
wdhwg001 · 2021-02-18 17:09:04 +08:00 · 3131 次点击这是一个创建于 1373 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，最近一直在写 FastAPI，有点腻了，想私底下玩点新的，也想拓宽一下视野。
不限语言的话，还有哪个 Web 框架可以做到：
- 全 Async / Await，用同步的写法写异步
- Annotation 式的 API 声明写法，这个是个人爱好，不喜欢集中式的路由
- 支持自动生成 OpenAPI 进行调试
- 依赖注入式的参数，自动验证进入 API 的请求
- 最好有全异步的 ORM，FastAPI 里我用的是 Tortoise-ORM，通讯层是异步的，而不是同步线程池。
- 最好性能比 FastAPI 高一些，更慢的就不考虑了
 |
1
laike9m 2021-02-18 17:17:07 +08:00 via Android  1
自己撸
|
 |
2
tabris17 2021-02-18 17:24:50 +08:00
不知道为啥，Python 下几个号称高性能的 web 框架（ Sanic 、FastAPI ），在 techempower 跑分都低得吓人
|
 |
3
jtsai 2021-02-18 17:27:17 +08:00
.net core
|
 |
4
wdhwg001 OP @tabris17 本身语言性能低吧，ASGI 也就比 WSGI 快一倍左右。
倒是 Spring 和 Gin 的跑分很低这件事让我蛮惊讶的。 |
 |
6
iConnect 2021-02-18 19:47:39 +08:00 via Android
现代框架都是有栈模式，不是 event loop 模式，这两张模式混合，很容易搞浆糊。
|
 |
7
shuimugan 2021-02-18 20:31:21 +08:00
NestJS
|
 |
8
liuhan907 2021-02-18 23:01:26 +08:00 via Android
要不你看看 actix-web ？
|
|
10
wdhwg001 OP |
 |
11
ericls 2021-02-18 23:39:00 +08:00 via iPhone
@tabris17 Python 框架只能在性能上减分 只要有框架 就有 overhead 性能应该是 server 做的事情。 但是这丝毫不影响你赚钱
|
|
12
ericls 2021-02-18 23:40:03 +08:00 via iPhone
自己写一个应该很容易 另外就像我说的 框架无关性能 都是 asgi 的 overhead.
|
|
13
wdhwg001 OP @shuimugan NestJS 之前试用过，但是现在看到它已经这么完善了还是有点惊讶，总的来说它的生态环境是比 FastAPI 更好的。
功能方面有我之前很痛点的 Session 支持一类的，功能更完整一些。 跑分方面大致比 FastAPI 高约 20%，而且因为是 V8，所以逻辑复杂了的话性能会甩的更开一些。 ORM 方面 TypeORM 也满足需求，功能比 Tortoise-ORM 更齐全，比如迁移一类的也都有。 如果不嫌弃 TypeScript 各种 JS 的智障遗产都有这一点的话，NestJS 已经可以直接替代 FastAPI 了。 |
|
14
shuimugan 2021-02-19 01:42:32 +08:00 2
@wdhwg001 NestJS 抄 Java 的 Spring 那一套，各种注入，这些注入都是单例，所以成员变量一般不会做写操作。但是这种注入的玩法和直接走 Class 的 static 函数调用没啥区别，看不出多有面向对象编程，目前看到这么做的好处就是做单元测试可以随意 Mock，以及在启动的时候预先实例化对象，避免涌进来的前几个请求慢一丢丢。
我最近才做完一个基于 Node 的代理网关的选型，可以给一些性能上的数据。 环境： CPU：8700k 默频 内存：4x16G C19 2666 频率 系统：Manjaro 20.2.1 Node 版本：14.15.4 写一个 hello work 接口，单 Node 进程运行，同时用 wrk 1 个线程去压测 纯内置 HTTP 库：QPS 3.8~3.9w, 内存占用 56~58MB Fastify：QPS 3.8~4w, 内存占用 58~62MB，开了控制台日志 QPS 在 2.2w 左右 NestJS(Fastify 适配器，使用单例注入的 Service)：QPS 3.6w ，内存占用 63MB 左右 NestJS(Fastify 适配器，使用了{ scope: Scope.REQUEST }参数注入的 Service，即一个请求实例化一个对象)：QPS 2.2w ，内存占用 81~105MB NestJS(Fastify 适配器，不使用注入 Service，自己 new Service)：QPS 3.1w ，内存占用 62MB NestJS(Fastify 适配器，不使用注入 Service，直接把 Service 的函数弄成 static 来调用)：QPS 3.6w ，内存占用 59~60MB 结论就是推荐使用 Fastify 的适配器，尽量走它的注入方式，比较工程化。 |
|
15
liuhan907 2021-02-19 23:07:43 +08:00
|
|
16
wdhwg001 OP @liuhan907 .net 5 + EF 的跑分大致上比 NestJS + TypeORM 快一倍左右，但我查到 EF 在多表时性能可能会被 Dapper 甩开 8 倍？
我想知道一下具体的情况是怎样的，以及在复杂场景下 EF 和 TypeORM 这样的东西相比体验如何。 确实，跨语言再跨框架的对比显得有些奇怪，不过既然只有这俩，并且 TS 的语法风格也很 C#，所以还是比一下好了。 我这边作为基础的对比，我可以首先确定 EF 的 LINQ 在用 Lambda 语法的时候吊锤 TypeORM 的 QueryBuilder，感觉就像在操作 pandas 一样方便。但你不是第一个和我提到 EF 性能存在问题的，然而大家都语焉不详，.net 社区在寻找答案的时候又经常会找到过期内容，所以这方面如果能说的更详细一些的话就再好不过了。 |
Select Language