嘿，大家好！

我还在努力打磨Gland，经过一番重构和研发，非常兴奋地分享一些新进展。Gland的最终形态越来越近了，我决定让它变成一个完全事件驱动的系统（基于EDS），受到了NestJS和Angular等框架的启发。

这表示

• 依赖注入系统：类似于 NestJS，支持简单的依赖注入功能。
• 控制器、导入、导出功能：类似于 NestJS，但有一个不同点——通道取代了传统提供者。
• 通道代替提供者：通道来处理逻辑，使应用程序更加模块化和易于扩展。
• 纯净轻量：自下而上构建，依赖项极少，不包含任何不必要的包——一切都是精简高效。

为什么选事件驱动系统 (EDS)?

而不是直接从控制器返回数据，Gland 中的所有操作都基于事件驱动。这使得应用更加模块化、易于扩展和灵活。事件触发相应的动作和响应，使整个流程更加顺畅和直观易懂。

示例

@Controller('users')
class UserController {
  @Get('/:id')
  getUser(ctx: Context) {
    const result = ctx.emit('read:server', ctx);
    try {
      throw Error('Hello world');
    } catch (error) {
      return ctx.emit('read:server:error', { error, result });
    }
  }
}

进入全屏，退出全屏

这里，ctx.emit('read:server', ctx) 发送一个名为 read:server 的事件，而一个 Channel 会监听这个事件。

    @Channel('users')
    class UserChannel {
      @On('read:服务器端')
      get(ctx: Context) {
        return 10;
      }
    }

全屏模式 退出全屏

现在整个数据流是事件驱动的。

下一步会是啥？

现阶段，Gland仍然处于开发阶段，想法还在不断变化。核心概念正在被逐步实现，我正在探索新的方式，让事件驱动架构在 web 开发中更直观些。

分享或贡献您的想法吧！

Gland 正在积极开发中，想法还在不断变化。如果你支持这个项目，欢迎点赞、提出问题、提交拉取请求，或在 GitHub 上分享你的想法。无论你发现了 bug 还是有新的功能构思，你的反馈非常珍贵。

我很想听听你的看法——与传统的模式相比，这种事件驱动的模式是否觉得更加灵活和模块化？或者你看到了潜在的难题？让我们聊一聊吧！