这是一个创建于 1318 天前的主题，其中的信息可能已经有所发展或是发生改变。
这个一个我个人开发 Node.js 框架，一个基于 TypeScript 的 Node.js 框架，底层基于 Koa 和 TypeDI，核心特性是使用依赖注入组织应用代码。
项目地址： https://github.com/forsigner/tie
为什么开发 TieJS，我刚开始用了两年多 Egg.js ，但是由于其对 TypeScript 支持过于弱(还有其他原因略过)，放弃 Egg.js 了，尝试使用了一个月 NestJS，由于其概念过于多、使用繁琐等原因也放弃了，所以开发了 TieJS，前后大概开发和维护了一年多时间。
我自己是 TypeScript 和 GraphQL，并且相比 Express，我更喜欢 Koa 的中间件系统，所以开发了 TieJS，核心特性是使用依赖注入组织应用代码，还有一个就是内置 GraphQL 的支持。
Tie 意为绳子，在 TieJS 中，最核心的单元是一个个 Injectable 的模块，通过依赖注入这根绳子，你可以有序地组织一个复杂的项目。也放弃了 NestJS 引入 Node 社区所有复杂的概念。
一些特性
TypeScript, 全面拥抱 TypeScript 依赖注入，易于编写可维护、可测试的代码 基于 Koa，易于可以复用 Koa 中间件生态 开箱即用，零配置开始项目 插件体系, 易于扩展
核心技术
TieJS 使用下面这些开源技术：
- Koa
- TypeDI
- TypeGraphQL
- TypeORM
- class-validator
这个框架因为个人原因，特性更新的比较慢，欢迎有兴趣的人一起维护和开发，如果有人有兴趣，我会把代码库转移到一个 Github 组织，并且开放开发权限，可以加我微信：ziyi-314，当然加微信普通交流也可以 哈哈
第 1 条附言 · 2021-05-20 19:31:58 +08:00
有 V友说有个群好交流，所以建个微信群 (或者加我微信 ziyi-314)：
33 条回复 • 2021-05-20 19:32:36 +08:00
 |
1
foranuttarachen 2021-05-18 12:11:21 +08:00
tie 有在实际的项目用到吗
|
 |
2
tinytin 2021-05-18 12:12:27 +08:00
关注下
|
 |
4
chogath 2021-05-18 12:15:24 +08:00
为什么不直接用 nest.js 呢 -0-
|
 |
5
forsigner OP @foranuttarachen 已经在几个商业项目跑了一年多了
|
|
6
forsigner OP @tinytin 最主要的是 NestJS 概念太多，太复杂，学习成本太高，降低了开发体验，对我个人而言，我只希望把 TypeScript 的 (类型安全) 和 依赖注入 (代码注入) 使用在 Node 框架中，Nest 强行把非常多 Spring 的概念和理念引入框架中，这不是我喜欢的，可能是个人品味的问题吧
|
 |
8
soshao1188 2021-05-18 12:28:05 +08:00
egg 的 typescript 有什么问题吗？看到也是支持的
|
|
9
chogath 2021-05-18 12:54:14 +08:00
感觉楼主没太想明白，node.js 的 web 框架各有优劣，使用哪种框架完全取决于工程场景。 类型安全和依赖注入也不是银弹。你给我的感觉是为了用而用 ...
|
 |
10
abersheeran 2021-05-18 12:59:31 +08:00
赞。我看看有没有好用的点可以抄的 hhh
|
 |
14
susan0007 2021-05-18 14:12:26 +08:00
强势围观
|
|
15
forsigner OP @chogath 所以你想表达我没想太明白什么？既然 [node.js 的 web 框架各有优劣，使用哪种框架完全取决于工程场景] ，你怎么得出别人创造一个东西是没使用场景的结论？
|
|
16
forsigner OP @soshao1188 eggjs 很好，有一个问题是它的 typescript 支持靠工具生产 d.ts 文件来解决的，实际使用会有很多不爽的地方
|
 |
17
ivens98 2021-05-18 15:14:10 +08:00
挺好的，但是没有大公司背书有点不敢用。
|
 |
18
agdhole 2021-05-18 16:14:03 +08:00
这类框架不敢用的唯一原因就是怕跑路
|
 |
19
yoa1q7y 2021-05-18 16:23:16 +08:00
看了下文档，感觉跟 nest.js 差不多，少了 Guards 、Pipes 等概念，然而你确定后面不会加上这些么
|
|
22
forsigner OP @yoa1q7y 不会，Guards 、Pipes 、filters 等东西在中间件处理已经很优雅，也很好理解，没必要创建那么多概念，而已它们之间还有功能交集，很容易让人困惑
|
|
23
yoa1q7y 2021-05-18 16:45:16 +08:00
@forsigner 然而 nest.js 官方文档对于每个概念也给出了充足的解释为什么要这么划分，每个概念有不同的使用场景。这么做确实提高了使用门槛和加大了理解难度，但是对于大型项目和多人合作项目，nest 这么做应该是有好处的
|
 |
25
EPr2hh6LADQWqRVH 2021-05-18 17:53:08 +08:00  1
挺好，我大概三年前也是和你类似的想法。
但我现在根本不拘泥于 HTTP 了，大家都只是 RPC 。 所以 Nest.js 和你这个我觉得都存在一个问题，只是程度不一样，就是太 HTTP 了。 抛弃掉路径的概念，整个过程更简单，更适合装饰器和类写法。 我现在用得最爽的是参数类，运行时自动类型检查和过滤。 |
|
27
soshao1188 2021-05-20 10:11:36 +08:00
我准备入坑你这个框架，搞个群大家多交流下。有问题也好解决啊
|
|
28
soshao1188 2021-05-20 16:22:25 +08:00
@forsigner 请问在吗？
|
|
32
forsigner OP @soshao1188 可以啊，那我建个群
|
|
33
forsigner OP @soshao1188 群有了，看文字结尾
|
Select Language