突然意识到,前端微应用也许是个伪需求

查看 67|回复 4
作者:aikilan   
最近基于 single-spa 拆分了日渐庞杂的一个前端工程,工程本身基于 vite 开发,子应用也全部使用 vite ,这中间大小坑多少也踩的差不多了,子应用的 hot reload/unmount/自动切换子应用的环境 /根据权限渲染子应用 /数据、权限、方法共享巴拉巴拉......
搞完以后,索然无味,突然意识到,这个改造的过程中,似乎终极目标就是让子应用的使用体验就像是写在同一个工程内一样,问题来了,既然终极目标就是写在同一个工程内,那么为什么一开始我要拆分呢?难道仅仅是为了一个概念上的“微前端”???
前端子应用的本质是为了追求独立部署(也许吧),但是在实际业务中,子应用很可能是一个看似独立实则业务与父应用高度耦合的模块,这就不可避免子应用调用父应用诸多业务实现,你很少有独立存在的必要(起码在我接触的业务中是这样的),这就意味着一旦子应用脱离了父应用的环境,你就需要为这些原本属于父应用的业务能力打补丁,这就显得很冗余。
如果父子应用都写在一个工程内,通过修改构建配置,实现独立打包 /部署,那么不但可以避免最开始那些需要踩的坑,还能轻松共享不同应用间的业务 /组件能力,所以诸如 single-spa 的出现,解决的是哪些真实业务场景需求呢?我很迷惑。当然了,搞技术的嘛,贵在折腾,于我个人而言,我还是有收获的。
最后,有折腾的机会我还是会去折腾的。

应用, 业务, vite, single-spa

musi   
single-spa 是让不同技术栈可以跑在一个项目里,比如说在 vue 里跑 react 。
如果你只是想做代码层级上的拆分,monorepo 就够了
aikilan
OP
  
@musi 是,这个确实属于需求点
wu67   
个人觉得, 是为了把现有的旧项目和新开的项目糅合在一起上线, 然后在后续的迭代过程中, 逐步重写替换旧应用.
如果是新开项目线这么折腾, 那我觉得真是没必要...
aikilan
OP
  
@wu67 业务的规划十分的庞大,给我一种错觉,"这玩意儿得特么上微应用了吧",实际业务来了以后,零零碎碎,笑死
您需要登录后才可以回帖 登录 | 立即注册

返回顶部