嘿,大家好!
我还在努力打磨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 还是有新的功能构思,你的反馈非常珍贵。
我很想听听你的看法——与传统的模式相比,这种事件驱动的模式是否觉得更加灵活和模块化?或者你看到了潜在的难题?让我们聊一聊吧!