新框架expressots，基本上和midway是一个路数。可以观望一下

@waitingsong 我这边是自己传trace的，我这只做函数，很多人以为集成是好处，是看似方便，但实际开发中经过一段时间弊端就会很大，所以我也避免集成，这样黑盒黑洞就不会出现。因为这两年我发现只要是新旧项目交接，都会因为这种集成的黑洞出现各种问题

没有生态，只能在小圈子里玩，算是小范围共识，期待spring boot 类似的盈利开源大杀器。

execute(@next() next: NextFunction)

这种写法，顶级要导入 next 装饰器方法，然后在 execute() 中又使用同名的变量，lint 会过不了的。 如果 execute() 内不使用同名变量（比如 execute(@next() nextFunc: NextFunction) ） 又很别扭。 换成

execute(@Next() next: NextFunction)

就舒服了，并且 Next 和 NextFunction 有对应关系，也提升效率

@httpGet @request 小驼峰风格装饰器函数名可能和业务代码的命名混淆或者冲突。 如果是大驼峰 @HttpGet @Request或者全大写可能比较好。

@zy445566 带上 otel 那套后性能如何呀

@i5ting https://cnodejs.org/topic/648fc19356d98349769da30a 之前同事做的压测也发过贴了就是

@zy445566 这倒是个思路，请求里调用栈里有fs等同步操作，可以更安全。

发出来看看。nest包的那么多，不会很快

@i5ting 真有vm,这个vm是用来现在某个模块是否可以使用系统的模块，比如某个模块或APP是否能使用fs模块。不过为了优化vm这块性能下了不少功夫，现在基本挺耐操的，之前同事压测过是nest.js的20倍性能

@i5ting 其实这个框架这个参数可以不写，里面都是有默认值的，可以直接这样写到方法上面就好，之所以写的这么清楚是为了让新手知道都有哪些参数 @Decorator.VaasServer()

@zy445566 架构图好唬人，看到vm吓我一跳，哈哈哈

@zy445566 还可以更简单

现在代码

// # src/apps/mini/index.ts
import {VaasServerType, Decorator } from 'vaas-framework'

export default class Mini {
    @Decorator.VaasServer({type:'http',method:'get',routerName:'/hello'})
    async hello({req,res}:VaasServerType.HttpParams) {
        return {
            hello:'world'
        }
    }
}

改后

// # src/apps/mini/index.ts
import {VaasServerType, Decorator } from 'vaas-framework'

export default class Mini {
    @VaasFun
    async hello({req,res}:VaasServerType.HttpParams) {
        return {
            hello:'world'
        }
    }
}

把http的path这些都干掉。改成约定式路由。参考 https://httpc.dev/docs/httpc-call-convention/

为什么用的人一定要理解http，method、query、param呢？娃哈哈

还是我这个学习成本低，直接函数上手，目前同事只要用过的都说用起来好爽 框架源码：https://github.com/virtual-less/vaas-framework 例子工程：https://github.com/virtual-less/vaas-template

源码地址 https://github.com/expressots/expressots