如题，最近一直在写 FastAPI，有点腻了，想私底下玩点新的，也想拓宽一下视野。
不限语言的话，还有哪个 Web 框架可以做到：
以及，主打有栈模式的现代语言只有 go 来着？
功能方面有我之前很痛点的 Session 支持一类的，功能更完整一些。
跑分方面大致比 FastAPI 高约 20%，而且因为是 V8，所以逻辑复杂了的话性能会甩的更开一些。
ORM 方面 TypeORM 也满足需求，功能比 Tortoise-ORM 更齐全，比如迁移一类的也都有。
如果不嫌弃 TypeScript 各种 JS 的智障遗产都有这一点的话，NestJS 已经可以直接替代 FastAPI 了。
我最近才做完一个基于 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 的适配器，尽量走它的注入方式，比较工程化。
我想知道一下具体的情况是怎样的，以及在复杂场景下 EF 和 TypeORM 这样的东西相比体验如何。
确实，跨语言再跨框架的对比显得有些奇怪，不过既然只有这俩，并且 TS 的语法风格也很 C#，所以还是比一下好了。
我这边作为基础的对比，我可以首先确定 EF 的 LINQ 在用 Lambda 语法的时候吊锤 TypeORM 的 QueryBuilder，感觉就像在操作 pandas 一样方便。但你不是第一个和我提到 EF 性能存在问题的，然而大家都语焉不详，.net 社区在寻找答案的时候又经常会找到过期内容，所以这方面如果能说的更详细一些的话就再好不过了。