谈谈大家对微前端的看法

9 天前
 JefZ

一个项目,有首页,搜索页,购买流程,账号页面,售后流程。 总代码 40 万行。除掉单测,快照,大概 20 万行。几十个前端开发协同工作。 React 项目,有完善的懒加载机制,服务端渲染。Router + Redux 。 由于公司收购,新公司的架构变更,这个项目要迁移到新的仓库,新的云供应商,新的项目外部依赖。 有人提议使用微服务来重新按 domain (首页,搜索这些)对这个项目使用微前端的概念来重构基础框架。 虽然是不同的 domain ,但是它们有相同的基础组件依赖,有公共逻辑依赖,状态在 Redux 。传统,规规矩矩。

下面是我个人在团队内提出的看法:

学识尚浅,有核心的东西没有考虑到吗?我不知道该用什么来作为辅助验证我说法的东西。

2313 次点击
所在节点    程序员
23 条回复
JefZ
7 天前
感谢大家提供参考

@shunia @tianzi123 @yimov2 @shadowyue @laommmm @shunia

> 增加后期心智负担

这是最恐怖的。我们现在的模式挺好的,新的框架基于 Next ,相当于提供了初始化项目的范式,正正常常,没有垂涎的优势,复杂度守恒,除了可以统一框架,不一定能带来什么优化,边际成本变多。


@beq

> 于是根据功能将其划分多个子系统,

哥你这个拆的太彻底了,这变成了彻底的前端微服务,每个子系统独立的很,我们应该没法和你们一样拆的这么彻底。

@rockey1997 @zy0829 @lee88688 @mygao666

> monorepo

好主意。深化一下我们现在的项目结构。

* 统一技术栈,项目按照 DDD 的思想,每个有边界的业务有自己的 domain ,几个 domian 结合起来就是 monorepo 中的一个 package 。现在我们不同的 domain 之间就互相干扰,每个团队这里引用一下那里导出一下,拆分成 package 也应该不会好转
* 独立,独立构建,独立配置,因为原来就是统一的栈,所以独立后,无非是复制一份基础的配置和构建过程。
* 项目的公共依赖,几乎每个 domain 都使用到了,没有一个 domain 有的依赖别的 domain 没有的场景。所以不存在依赖管理的问题。
* CICD 么,bundles 包都被上传到了 CDN ,要服务器没有用。只有主应用因为要 SEO 和服务器端逻辑才需要服务器。大部分 domain 就安静的待着,没有服务端逻辑,静态文件服务都不需要。

这种情况下,monorepo 的优势在哪里呢?因为没有做过,所以无法理解真实的项目问题和好处。

@jones2000

> 聚合网关

我们有 BFF 。BFF 也要迁移。这就是另外的问题了。涉及到 BFF 和后端的访问延迟,访问权限。

----

补充背景:
这个主题主要是关注技术,但是我想增加一些额外的东西来说明我们除了技术上的选择,还有非技术的压力。
新的公司架构有一套自己的,封装了 Next 的框架,围绕着这个框架有很多额外的依赖(比如翻译,配置)。高层决策希望统一技术栈。我们自己也挺想用新的体系,问题在于不想为了统一而统一,因为我们属于成熟项目,大家不都说理想的技术决策是基于理性表达代码嘛。
JefZ
7 天前
果然对于旁人的痛苦是缺乏想象力的,
写代码的人才会真正在乎改动带来的困难,后期开发的复杂度,心智负担重,debug 变得更难,性能不好了。
mygao666
7 天前
@JefZ #22 哥们,写个代码这么痛? 有代码洁癖么?

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1071651

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX