一个装饰器风格,依赖注入,OOP的Web框架
发布于 25 天前 作者 axetroy 742 次浏览 来自 分享

基于在上一家公司的开发经验,沉淀而来的web框架。

Kost 基于 Koa,使用 Typescript 编写,借鉴于 egg 的约定大于配置的思想以及 nest 的依赖注入和装饰器路由。

是一款内置多个功能,并遵循一系列规范的 Web 框架。

框架架构

kost

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

12 回复

朝着serverless走吧,常规web框架太多,优势不大

@i5ting

确实是,常规框架现在都区别不大。server less这个,如果是用第三方平台,那得依赖于他们的服务啊,数据也存储在别人的地方,在有些人眼里就是不可靠啊

来自酷炫的 CNodeMD

而且 egg 的 service 会丢失类型 IDE 提示

@axetroy 其实就是手写 d.ts 就搞定了,我们在做的是自动生成 d.ts ,但其实手写也非常简单。

// app/service/index.d.ts
import AccountService from './Account';
import FileService from './File';
declare module 'egg' {
  interface IService {
    account: AccountService;
    file: FileService;
  }
}

@atian25 手写终归不是个好办法,自动生成就好棒了

来自酷炫的 CNodeMD

@axetroy 你仔细看上面那段代码,不用分析什么 AST ,就是一个目录遍历就能生成了

@i5ting 我们已经用上自己研发的serverless了,狼叔推荐一个 From Noder

@einsqing serverless可以写篇文章,学习下

@ImHype 要做koa框架,我觉得思路都是一样的,无非是把 控制、路由、服务、中间件、模型、页面等通过注入的方式联系起来,少写代码。 脱离不了窠臼,再上两个框架,估计还是惊人的相似……

@wujianqi

既然惊人的相似,为何大家总是孜孜不倦的造相似的轮子呢,只不过是用别人的可能不符合自己平时的开发习惯(不论谁的风格习惯好坏),所以就撸一个对于自己来说顺手的。

而像egg这类的框架,有多个大牛开发,踩了很多平常人踩不到的坑,最后得出的一个最佳实践,再次给它点个赞👍

大部分小团队都没有这种实力去开发或长久的维护。

框架这类东西,适合自己的才是最好的。

怎么样才是适合自己的?

私以为:

  1. 写法/风格与自己或团队契合
  2. 自己比较清楚内部运作原理

来自酷炫的 CNodeMD

回到顶部