Midway 2023 Roadmap

[czy88840616]

得益于社区用户的不断壮大，Midway 的能力也愈发完善。现阶段，Midway 提供了 Web 场景（egg 2/koa/express）的完整支持，也提供了 Socket.io/WebSocket 的相关适配能力，这使得开发 Web 应用越来越简单。

在微服务方面，也随着 Grpc + etcd 的能力加入进来，这一块能力也有了部分满足，但是在服务发现场景还有缺失，比如 nacos，zookeeper 等均未提供官方支持。

在 Serverless 场景方面，由于国内 Serverless 的前景不明朗，我们也收敛了这方面的投入，从原有的自己管理构建，部署，转为 由 Serverless Devs 工具自行部署。

此外，CLI 工具也将逐渐切换为社区现有的 tsc 等工具，不再过度包装。

参考了现有社区库的形态，目前提供了 issue + Discussions 的两部分，issue 将只保留提 bug，提交 feature request 和 文档问题三个部分的能力，其余都将引导到 Discussion 进行讨论。

虽然也快到年底了，还是要写一下当前开发的一些计划。

性能优化计划

• 1、现有的 @midwayjs/logger 库已经有一阵子没有迭代，基于 winston 的性能不算特别好，而且依赖链非常深，在密集打日志的场景下有瓶颈
• 2、在 async_local_storage 以及基本覆盖的情况下，请求作用域可以基于新的方式来实现，不再需要每次请求都创建一堆对象，可以提升较大的性能

和前端的结合

一体化算是之前的一个前端结合尝试，现阶段的维护人员已经无法继续，而且对接前端框架的成本也挺高，从 cli 到 API 都做了一遍适配。

最开始的目标是希望有一个轻量的方案能够去适配 react/vue + 其他的前端组件库，在 babel/vite 的场景上，应该有其他的简化方案。现在 nextjs 也比较热门，可以尝试先结合一下看看。

装饰器元数据

一直被人诟病的装饰器继承问题，本质上是元数据无法继承，由于装饰器提案之前一直没有确定不太敢大改，现阶段基本上已经明确，https://github.com/tc39/proposal-decorators 和 https://github.com/tc39/proposal-decorator-metadata 都已经进入 stage3，可以接着进行调整。

Profiler 的一些能力

编写 Node.js 的用户，如果项目稳定运行之后，经常会考虑到进行性能问题排查，原有的 code-dye 等组件在大场景下杯水车薪，计划会有一个 profiler 的能力，从框架层输出一些执行时间打点，辅助进行问题的排查。

---

以上仅仅是一些大方向的计划，会涉及到框架非常大的改造和重构。新的组件之类的需求，视时间而定，不在上述大方向的计划内。此外，计划肯定是赶不上变化，时间点不会很明确。

关于 Midway4，现阶段没有计划，Midway 3 的架构已经能满足现阶段所有的场景，不需要新的版本。

[xmsz-stu]

一体化为什么没人维护了

[czy88840616]

人员职责变更。

[xmsz-stu]

好吧 那一体化这个会有可能继续做吗 我现在尝试用remix的方案实现

[czy88840616]

当前各个前端框架都有类似的实现，比如 nextjs，midway 会以更加轻量的方式来做集成。