Midway 2024 Roadmap #3641
Replies: 4 comments 7 replies
-
|
其实可以考虑先把相对旧的一些在组件服务抽象先做做.实际项目中对组件和工程上的处理是最多最频繁的. |
Beta Was this translation helpful? Give feedback.
-
|
有些是可以的，所以现在在双开。 |
Beta Was this translation helpful? Give feedback.
-
|
我是很喜欢midway的，不管从文档，代码规范和分隔等，使用起来都很顺眼+顺手（顺眼的意思是，代码看起来相对规整但又不像egg基于约束，比较自由；顺手是指满足现在web开发的多数场景，且ts，毕竟被eggjs心智折磨过了）。 egg with ts的路径我尝试过，小项目可以直接用。 我将在我的下个项目中，使用midway，希望一切顺利。 |
Beta Was this translation helpful? Give feedback.
-
|
从产品人员来说现在关系不大，egg/tegg 是蚂蚁集团在维护而 midway 是阿里集团淘天在维护，交集很少，除非涉及到整体安全性（比如前段时间的三方 cookie 问题，会简单讨论下怎么处理以及各自实现）。 从功能来说 midway 本身只是一个 ioc 容器发展起来，更像是一个胶水层，有一套自己的加载，扩展，融合机制，而 egg 我们定位是 web 层框架，是可以被替换的，所以现在会有 @midwayjs/koa, @midwayjs/web，@midwayjs/express，甚至 @midwayjs/nextjs... 所以也不仅限于 web 范畴，会有独立的微服务体系（@midwayjs/grpc 等），定时任务体系（@midwayjs/bull/cron 等）。 |
Beta Was this translation helpful? Give feedback.
-
|
用 TS 写 egg 的扩展才是痛苦，还不好调试…… |
Beta Was this translation helpful? Give feedback.
-
|
我最近在搞企业的后台，在找一个合适的框架 希望前后端开发最好可以一体化。因为这个后台就一个人搞，一个人一体化效率最高。 然后选型的话。 第一种：还是拆前后端项目，前端react随便，后端更偏向midway，因为有很多解决方案能直接套用很方便，比如JWT等，这些都是基础的，但是一般后端项目都要自己再封装一层... 所以我觉得组件这个东西真的不错，就应该实现这样即插即用方向。其他产品比如koa(要封装)、egg(开发体验差) 第二种：用ssr来实现，比如nextjs，就是很多前端项目都支持的能力，优点就是可以用nodeJS能力，缺点就是太简易了和硬用。 第三种：一体化hooks，就是之前midway一体化实现的那种，优点就是可以用nodeJS能力，缺点也是太简易了，加上各种组件以后和完整项目没区别 第四种：真一体化，比如MetroJS/RemixJS，我现在在尝试中... 然后，还有一个就是关于什么时候使用midwayJS 如果是完整项目，那肯定用其他语言写后端，比如golang 当然，如果是一个人的小团队做小项目是可以。 所以，在场景上，完整项目比不过其他语言，甚至比不过egg(毕竟国内绝大部分用nodejs写后端的人都没啥追求，能实现就行)，如果要走简单项目，那写起来就要简单一些（类似vue，屏蔽概念，新手友好，能用）。如果走一体化，那感觉没啥能干过现有主流框架。 还有很好玩的几点，第一个如果你是前端项目+typescript，那会有效果；如果是nodeJS包+typescript也有用。但是nodejs后端框架+typescript就好像效果很不明显，原因前面也说了，使用人的问题。 |
Beta Was this translation helpful? Give feedback.
-
|
现有的前端模块，包括 Next 等 SSR 框架，更多的是在路由，鉴权，渲染层面，不会涉及到服务端领域（RPC/服务发现/数据分层/流量管理等），后者是 Midway 一直在努力深入的，现在国内也没有任何框架在这条路上走，即使是 egg。 Midway 之前的一体化，是在服务端之上，往前探索了一阵子，我们发现 CSR/SSR 不是 Midway 擅长的领域，所以目前一体化是停滞的，后面我们所谓的一体化，更多是依赖现有的社区能力（next 等），和 Midway 的能力结合起来，会提供类似 @midwayjs/nextjs 类似的组件将 SSR 框架集成进来，不会过度封装。通过组合的形式会让前后端开发更顺畅，这样也能复用各自的能力。 另外，企业的后台，管理平台我认为是 Node 目前所擅长的领域，有大量前端的资源可以投入，也有足够的前端 admin 模版可以使用，这一块 Midway 会提供相应的 admin 配套。 |
Beta Was this translation helpful? Give feedback.
-
|
midwayjs有类似https://github.com/szymmis/vite-express的解决方案吗？ |
Beta Was this translation helpful? Give feedback.
-
|
vite的确在考虑的范围内，主要是用他来启动编译，集成 dev server 等。 |
Beta Was this translation helpful? Give feedback.
-
|
只是把Vite的开发以及构建过程集成进去就很方便开发了，代码层面应该挺简单的 |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
随着 2024 的到来，2023 的一些特性的补充，能力也越来越完善，大家会发现 Midway 在特定能力（Web）场景已经补充的差不多，很多都是组件层面的修修补补。
一是因为核心 core 模块已经非常的稳定了，已经抽象到了一个比较轻量且易扩容的维度，另一方面，组件的更新本身就会频繁很多。在这种场景下，大家看到每次更新几乎都是组件的变化，新增一些 API，透出一些 class 等。
很多人会问，Midway 的下一个版本是什么时候？去年底这个问题还没有答案，毕竟核心足够稳定，看来还足以支撑很长一段时间，而大版本势必会影响比较大的 Breaking，对业务来说，频繁的升级，不是一个好事情。
有人说，Midway 宣传不够，这个我们认，宣传会有批量的用户涌入试用，有人气有渠道有话题。就目前而言，有一个国外的牌子会更容易吸引用户，不过现在出生在国内，也没什么好抱怨的，我们能做的，就是做好功能，写好文档，服务好现有的用户。至于每次必提的 KPI 产物，笑笑就过去了，这 KPI 的时间也太长了，事实上 Midway 早就脱离了阿里本身给他的定位和命题，现有的产品早就超出了当初的规划和能力。在当前这个互联网环境下，整个团队需要活下去，当下活下去比宣传更为重要，毕竟 Midway 并不是一个盈利性质的产品，更新宣传是一个机会，但是很容易变成一个暴死的机会。
回归到功能本身，最近在研发 HMR 的能力，发现又牵扯到 decorator 的 metadata，恰好 ts5 又大改了这块 API，所以这个新的版本的机会就来了。
目前的计划有几块：
新的装饰器规范来实现功能（新装饰器规范仍然不支持参数装饰器，且元数据规范的变更会使得 typeorm，sequelize-typescrip 等库失去作用）支持装饰器继承Beta Was this translation helpful? Give feedback.
All reactions