FastAPI 玩腻了，全异步、注解式、支持 OpenAPI、带参数验证的框架还有啥，不限语言

[wdhwg001]

如题，最近一直在写 FastAPI，有点腻了，想私底下玩点新的，也想拓宽一下视野。

不限语言的话，还有哪个 Web 框架可以做到：

• 全 Async / Await，用同步的写法写异步
• Annotation 式的 API 声明写法，这个是个人爱好，不喜欢集中式的路由
• 支持自动生成 OpenAPI 进行调试
• 依赖注入式的参数，自动验证进入 API 的请求
• 最好有全异步的 ORM，FastAPI 里我用的是 Tortoise-ORM，通讯层是异步的，而不是同步线程池。
• 最好性能比 FastAPI 高一些，更慢的就不考虑了

[laike9m]

自己撸

[tabris17]

不知道为啥，Python 下几个号称高性能的 web 框架（ Sanic 、FastAPI ），在 techempower 跑分都低得吓人

[jtsai]

.net core

[wdhwg001]

@tabris17 本身语言性能低吧，ASGI 也就比 WSGI 快一倍左右。
倒是 Spring 和 Gin 的跑分很低这件事让我蛮惊讶的。

[wdhwg001]

@jtsai 果然对标的只有 C#吗，感觉香是真的香，但是国内也确实冷门了点。

[iConnect]

现代框架都是有栈模式，不是 event loop 模式，这两张模式混合，很容易搞浆糊。

[shuimugan]

NestJS

[liuhan907]

要不你看看 actix-web ？

[wdhwg001]

@liuhan907 但是 diesel 是同步线程池的…就有点可惜了。

[wdhwg001]

@iConnect 有栈模式在 web 环境下比不过无栈吧？毕竟 web 场景下 io 密集而计算不密集，有栈会破坏预测并且需要频繁切栈和分配内存。

以及，主打有栈模式的现代语言只有 go 来着？

[ericls]

@tabris17 Python 框架只能在性能上减分 只要有框架 就有 overhead 性能应该是 server 做的事情。 但是这丝毫不影响你赚钱

[ericls]

自己写一个应该很容易 另外就像我说的 框架无关性能 都是 asgi 的 overhead.

[wdhwg001]

@shuimugan NestJS 之前试用过，但是现在看到它已经这么完善了还是有点惊讶，总的来说它的生态环境是比 FastAPI 更好的。

功能方面有我之前很痛点的 Session 支持一类的，功能更完整一些。

跑分方面大致比 FastAPI 高约 20%，而且因为是 V8，所以逻辑复杂了的话性能会甩的更开一些。

ORM 方面 TypeORM 也满足需求，功能比 Tortoise-ORM 更齐全，比如迁移一类的也都有。

如果不嫌弃 TypeScript 各种 JS 的智障遗产都有这一点的话，NestJS 已经可以直接替代 FastAPI 了。

[shuimugan]

@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 的适配器，尽量走它的注入方式，比较工程化。

[liuhan907]

@wdhwg001 确实目前 Diesel 是同步的比较遗憾，如果要完全满足你提的需求的看来看去貌似还真就只有 ASP.NET Core 才能满足了。EFCore 是真的好用，而且.NET6.0 微软也在着手改善性能问题。目标是持平 Dapper 但是有点难感觉，不过目前的性能用于 Web 服务我感觉绝对是够用了。

[wdhwg001]

@liuhan907 .net 5 + EF 的跑分大致上比 NestJS + TypeORM 快一倍左右，但我查到 EF 在多表时性能可能会被 Dapper 甩开 8 倍？

我想知道一下具体的情况是怎样的，以及在复杂场景下 EF 和 TypeORM 这样的东西相比体验如何。

确实，跨语言再跨框架的对比显得有些奇怪，不过既然只有这俩，并且 TS 的语法风格也很 C#，所以还是比一下好了。

我这边作为基础的对比，我可以首先确定 EF 的 LINQ 在用 Lambda 语法的时候吊锤 TypeORM 的 QueryBuilder，感觉就像在操作 pandas 一样方便。但你不是第一个和我提到 EF 性能存在问题的，然而大家都语焉不详，.net 社区在寻找答案的时候又经常会找到过期内容，所以这方面如果能说的更详细一些的话就再好不过了。

[liuhan907]

@wdhwg001 其实很多时候说 ef 性能存在问题，并不是说真的有很糟的性能，而是在说这个东西相对 dapper 性能差。另外 ef 在第一次查询的时候因为要做代码生成，同时默认查询会跟踪数据变化，因此性能相对 ADO 当然是差。但是一些人只测试了简单的查询，也不预热，所以就得出 ef 性能比较差。虽然确实有差距不过根据测试也就仅仅相对 ADO 损失 30%而已。