基于在上一家公司的开发经验,沉淀而来的web框架。
Kost 基于 Koa,使用 Typescript 编写,借鉴于 egg 的约定大于配置的思想以及 nest 的依赖注入和装饰器路由。
是一款内置多个功能,并遵循一系列规范的 Web 框架。
框架架构

Q & A
Q: 为什么开发这样的框架
A: 框架基于以前的项目经验沉淀而来,首先是坚持 Typescript 不动摇,能在开发阶段避免了很多 bug。
Q: 为什么不使用 nest?
A: 因为它是基于 Express,而我以前的项目都是 Typescript + Koa
Q: 为什么不使用 egg?
A: egg 使用 JS 开发,目前对 Typescript 没有一个很好的方案(见识短,没发现),而且 egg 的 service 会丢失类型 IDE 提示,目前 egg 成员已在着手解决这个问题,期待中…
Q: 与两者的框架区别在哪里?
A: 借鉴了 egg 的约定大于配置的思想,约定了一些文件目录,文件名,如果不按照框架写,就会 boom。借鉴了 nest 的 OOP 编程思想,所有的,包括 Controller、Service、Middleware 都是类,都可以进行依赖注入,而且路由定义是装饰器风格,语法糖会让你更加的直观。对于开发而言,会有很好的 IDE 提示。
Q: 框架内置了一些特性,会不会平白增加性能负担?
A: 根据你是否开启特性,来决定是否引入包,所以不会有性能损耗。
Q: 是否需要配套 CLI 工具?
A: 目前没有,编译成 JS 就能运行,可以用 pm2 进行负载均衡。
Q: 框架是否包含进程管理?
A: 框架本身不进行进程管理,没有类似 egg 的 master 主进程管理子进程,没有 agent
何为开源
开源就是自己用的爽的东西,拿出来给大家用,然后发现你自己写的,用法和原理你肯定懂啊,但是别人不懂,你得写文档,维护文档的时间,不必写代码的时间少。
同时为了保证项目质量,你还得写测试用例,写测试用例的时间,也并不少。
要维护一个开源项目,真的是要花不少心思,向开源大牛致敬。
总结
实现起来没什么难度,前人栽树,后人乘凉,继承自Koa的类,然后在start之前,做一些初始化动作,加载Controller,验证Controller、Middleware、Service是否正确,加载配置文件等工作…
从创建仓库到现在100+个commit,而大多数commit都是更新文档,添加测试用例,最近也忙,断断续续的维护,今天终于完善了测试用例,覆盖率99%,终于可以发布第一个版本。
有兴趣的小伙伴,一起来维护吗,交个朋友
最后上项目地址: https://github.com/axetroy/kost
朝着serverless走吧,常规web框架太多,优势不大
@i5ting
确实是,常规框架现在都区别不大。server less这个,如果是用第三方平台,那得依赖于他们的服务啊,数据也存储在别人的地方,在有些人眼里就是不可靠啊
来自酷炫的 CNodeMD
赞
@axetroy 其实就是手写 d.ts 就搞定了,我们在做的是自动生成 d.ts ,但其实手写也非常简单。
@atian25 手写终归不是个好办法,自动生成就好棒了
来自酷炫的 CNodeMD
@axetroy 你仔细看上面那段代码,不用分析什么 AST ,就是一个目录遍历就能生成了
@i5ting 我们已经用上自己研发的serverless了,狼叔推荐一个 From Noder
@einsqing serverless可以写篇文章,学习下
@axetroy 这是我造的轮子,惊人的相似 https://github.com/easy-koa/easy-koa
测试一下
@ImHype 要做koa框架,我觉得思路都是一样的,无非是把 控制、路由、服务、中间件、模型、页面等通过注入的方式联系起来,少写代码。 脱离不了窠臼,再上两个框架,估计还是惊人的相似……
@wujianqi
既然惊人的相似,为何大家总是孜孜不倦的造相似的轮子呢,只不过是用别人的可能不符合自己平时的开发习惯(不论谁的风格习惯好坏),所以就撸一个对于自己来说顺手的。
而像egg这类的框架,有多个大牛开发,踩了很多平常人踩不到的坑,最后得出的一个最佳实践,再次给它点个赞👍
大部分小团队都没有这种实力去开发或长久的维护。
框架这类东西,适合自己的才是最好的。
怎么样才是适合自己的?
私以为:
来自酷炫的 CNodeMD
不错的项目,学习下!我以前也想自己做一个,无奈一直没时间。想问下你总共开发多久做的这个轮子啊? 对了nest现在支持fastify了,比koa执行效率还要快一些
厉害