Midway 2024 Roadmap

[czy88840616]

随着 2024 的到来，2023 的一些特性的补充，能力也越来越完善，大家会发现 Midway 在特定能力（Web）场景已经补充的差不多，很多都是组件层面的修修补补。

一是因为核心 core 模块已经非常的稳定了，已经抽象到了一个比较轻量且易扩容的维度，另一方面，组件的更新本身就会频繁很多。在这种场景下，大家看到每次更新几乎都是组件的变化，新增一些 API，透出一些 class 等。

很多人会问，Midway 的下一个版本是什么时候？去年底这个问题还没有答案，毕竟核心足够稳定，看来还足以支撑很长一段时间，而大版本势必会影响比较大的 Breaking，对业务来说，频繁的升级，不是一个好事情。

有人说，Midway 宣传不够，这个我们认，宣传会有批量的用户涌入试用，有人气有渠道有话题。就目前而言，有一个国外的牌子会更容易吸引用户，不过现在出生在国内，也没什么好抱怨的，我们能做的，就是做好功能，写好文档，服务好现有的用户。至于每次必提的 KPI 产物，笑笑就过去了，这 KPI 的时间也太长了，事实上 Midway 早就脱离了阿里本身给他的定位和命题，现有的产品早就超出了当初的规划和能力。在当前这个互联网环境下，整个团队需要活下去，当下活下去比宣传更为重要，毕竟 Midway 并不是一个盈利性质的产品，更新宣传是一个机会，但是很容易变成一个暴死的机会。

回归到功能本身，最近在研发 HMR 的能力，发现又牵扯到 decorator 的 metadata，恰好 ts5 又大改了这块 API，所以这个新的版本的机会就来了。

目前的计划有几块：

• 1、框架使用 ts5 来开发构建，node 版本支持从 v16 开始
• 2、使用 新的装饰器规范来实现功能 （新装饰器规范仍然不支持参数装饰器，且元数据规范的变更会使得 typeorm，sequelize-typescrip 等库失去作用）支持装饰器继承
• 3、框架级别的 HMR 功能
• 4、和前端融合的更好，函数形式的框架 API

[flyingcrp]

其实可以考虑先把相对旧的一些在组件服务抽象先做做.实际项目中对组件和工程上的处理是最多最频繁的.

[czy88840616]

有些是可以的，所以现在在双开。

[minefujiko9293]

我是很喜欢midway的，不管从文档，代码规范和分隔等，使用起来都很顺眼+顺手（顺眼的意思是，代码看起来相对规整但又不像egg基于约束，比较自由；顺手是指满足现在web开发的多数场景，且ts，毕竟被eggjs心智折磨过了）。

egg with ts的路径我尝试过，小项目可以直接用。
但是还有个tegg，我也不知道他和midway之间到底是如何区别他们的定位的哈，简单看了快速入手示例后，感觉和midway有点重复了，有空可以为我们解答下。毕竟egg和midway也基本占据了国内nodejs后端开发的大半江山了

我将在我的下个项目中，使用midway，希望一切顺利。
最后谢谢midway团队！

[czy88840616]

从产品人员来说现在关系不大，egg/tegg 是蚂蚁集团在维护而 midway 是阿里集团淘天在维护，交集很少，除非涉及到整体安全性（比如前段时间的三方 cookie 问题，会简单讨论下怎么处理以及各自实现）。

从功能来说 midway 本身只是一个 ioc 容器发展起来，更像是一个胶水层，有一套自己的加载，扩展，融合机制，而 egg 我们定位是 web 层框架，是可以被替换的，所以现在会有 @midwayjs/koa, @midwayjs/web，@midwayjs/express，甚至 @midwayjs/nextjs...

所以也不仅限于 web 范畴，会有独立的微服务体系（@midwayjs/grpc 等），定时任务体系（@midwayjs/bull/cron 等）。

[waitingsong]

用 TS 写 egg 的扩展才是痛苦，还不好调试……

[xmsz-stu]

我最近在搞企业的后台，在找一个合适的框架

希望前后端开发最好可以一体化。因为这个后台就一个人搞，一个人一体化效率最高。
比如，同个端口开发不用多开项目，类型文件互通不用重复写或生成，同个语言写不用切换，只需要部署一个不用配多个..
相当于在技术上就是简单的小项目，只需要实现快和方便其他不需要考虑

然后选型的话。

第一种：还是拆前后端项目，前端react随便，后端更偏向midway，因为有很多解决方案能直接套用很方便，比如JWT等，这些都是基础的，但是一般后端项目都要自己再封装一层... 所以我觉得组件这个东西真的不错，就应该实现这样即插即用方向。其他产品比如koa(要封装)、egg(开发体验差)

第二种：用ssr来实现，比如nextjs，就是很多前端项目都支持的能力，优点就是可以用nodeJS能力，缺点就是太简易了和硬用。

第三种：一体化hooks，就是之前midway一体化实现的那种，优点就是可以用nodeJS能力，缺点也是太简易了，加上各种组件以后和完整项目没区别

第四种：真一体化，比如MetroJS/RemixJS，我现在在尝试中...

---

然后，还有一个就是关于什么时候使用midwayJS

如果是完整项目，那肯定用其他语言写后端，比如golang
如果是简单的小项目，理论上koaJS就行
如果是更简单的小项目，函数计算就行

当然，如果是一个人的小团队做小项目是可以。

所以，在场景上，完整项目比不过其他语言，甚至比不过egg(毕竟国内绝大部分用nodejs写后端的人都没啥追求，能实现就行)，如果要走简单项目，那写起来就要简单一些（类似vue，屏蔽概念，新手友好，能用）。如果走一体化，那感觉没啥能干过现有主流框架。

还有很好玩的几点，第一个如果你是前端项目+typescript，那会有效果；如果是nodeJS包+typescript也有用。但是nodejs后端框架+typescript就好像效果很不明显，原因前面也说了，使用人的问题。
第二个，未来方向上，除了AI。 之前就是SSR和Serverless，SSR几乎都是标配了，但是SSR因为需求和实现简单没必要用nodeJS框架，而serverless了现在都函数化或者其他语言，所以这两个对midway的影响力也没帮助

[czy88840616]

现有的前端模块，包括 Next 等 SSR 框架，更多的是在路由，鉴权，渲染层面，不会涉及到服务端领域（RPC/服务发现/数据分层/流量管理等），后者是 Midway 一直在努力深入的，现在国内也没有任何框架在这条路上走，即使是 egg。

Midway 之前的一体化，是在服务端之上，往前探索了一阵子，我们发现 CSR/SSR 不是 Midway 擅长的领域，所以目前一体化是停滞的，后面我们所谓的一体化，更多是依赖现有的社区能力（next 等），和 Midway 的能力结合起来，会提供类似 @midwayjs/nextjs 类似的组件将 SSR 框架集成进来，不会过度封装。通过组合的形式会让前后端开发更顺畅，这样也能复用各自的能力。

另外，企业的后台，管理平台我认为是 Node 目前所擅长的领域，有大量前端的资源可以投入，也有足够的前端 admin 模版可以使用，这一块 Midway 会提供相应的 admin 配套。

[ckvv]

midwayjs有类似https://github.com/szymmis/vite-express的解决方案吗？

[czy88840616]

vite的确在考虑的范围内，主要是用他来启动编译，集成 dev server 等。

[ckvv]

只是把Vite的开发以及构建过程集成进去就很方便开发了，代码层面应该挺简单的

[xmsz-stu]

1. 是的，以前端为主的框架大多都是通过SSR来间接实现
2. 服务端领域的深入，如微服务/RPC/流量控制，对于复杂项目来说都是必须的。但我觉得除了大公司(sofa-rpc)，大部分人用nodejs做后端都用不到。我们用的最多也就是和已有后端服务通信，更多人可能纯粹只要个能查中文文档的。
3. 是的，管理后台用nodejs最舒服，毕竟大多数场景就是查询和展示数据