A Typescript + Node.js lightweight framework for quick building scalable, easy to read and maintain, server-side applications 🐎
看了一眼,ioc、装饰圈,面向对象,ts。基本上和midway是一个路数。可以观望一下
controller
@controller("/")
class AppController {
@httpGet("/")
execute(@response() res: any) {
return res.send("Hello from ExpressoTS!");
}
}
模型
@provide(User)
class User {
private id: string;
public name: string;
public email: string;
constructor() {
this.id = uuidv4();
}
get Id(): string {
return this.id;
}
}
各种装饰器
https://doc.expresso-ts.com/docs/overview/decorators
代码目前还很挫 有一颗menorepo的心,却没有menorepo的命
看看这依赖,瞎用。
"dependencies": {
"@commitlint/cli": "^17.5.1",
"@commitlint/config-conventional": "^17.4.4",
"@release-it/conventional-changelog": "^5.1.1",
"chalk": "^4.1.2",
"dotenv": "^16.0.3",
"express": "^4.18.2",
"husky": "^8.0.3",
"inversify": "^6.0.1",
"inversify-binding-decorators": "^4.0.0",
"inversify-express-utils": "^6.4.3",
"jest": "^29.5.0",
"reflect-metadata": "^0.1.13",
"release-it": "^15.9.3",
"winston": "^3.8.2",
"winston-daily-rotate-file": "^4.7.1"
},
"devDependencies": {
"@types/express": "^4.17.17",
"@types/jest": "^29.5.0",
"@types/node": "^18.15.11",
"prettier": "3.0.0",
"ts-jest": "^29.0.5",
"typescript": "^5.0.3"
},
- winston不如pino
- 基于express + inversify实现的ts版本
- 目前看品味一般
- 目前star数700多
按照这种情况,去蹭pr三非常容易的。
还是我这个学习成本低,直接函数上手,目前同事只要用过的都说用起来好爽 框架源码:https://github.com/virtual-less/vaas-framework 例子工程:https://github.com/virtual-less/vaas-template
@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呢?娃哈哈
@zy445566 架构图好唬人,看到vm吓我一跳,哈哈哈
@i5ting 其实这个框架这个参数可以不写,里面都是有默认值的,可以直接这样写到方法上面就好,之所以写的这么清楚是为了让新手知道都有哪些参数 @Decorator.VaasServer()
@i5ting 真有vm,这个vm是用来现在某个模块是否可以使用系统的模块,比如某个模块或APP是否能使用fs模块。不过为了优化vm这块性能下了不少功夫,现在基本挺耐操的,之前同事压测过是nest.js的20倍性能
@zy445566 这倒是个思路,请求里调用栈里有fs等同步操作,可以更安全。
发出来看看。nest包的那么多,不会很快
@i5ting https://cnodejs.org/topic/648fc19356d98349769da30a 之前同事做的压测也发过贴了就是
@zy445566 带上 otel 那套后性能如何呀
@httpGet
@request
小驼峰风格装饰器函数名可能和业务代码的命名混淆或者冲突。
如果是大驼峰 @HttpGet
@Request
或者全大写可能比较好。
execute(@next() next: NextFunction)
这种写法,顶级要导入 next
装饰器方法,然后在 execute()
中又使用同名的变量,lint 会过不了的。
如果 execute()
内不使用同名变量(比如 execute(@next() nextFunc: NextFunction)
) 又很别扭。
换成
execute(@Next() next: NextFunction)
就舒服了,并且 Next
和 NextFunction
有对应关系,也提升效率
没有生态,只能在小圈子里玩,算是小范围共识,期待spring boot 类似的盈利开源大杀器。
@waitingsong 我这边是自己传trace的,我这只做函数,很多人以为集成是好处,是看似方便,但实际开发中经过一段时间弊端就会很大,所以我也避免集成,这样黑盒黑洞就不会出现。因为这两年我发现只要是新旧项目交接,都会因为这种集成的黑洞出现各种问题