你还在说webpack慢?也许需要在架构方面考虑优化问题。

5,598 阅读5分钟

现在vite已经被炒的很火,但它也只是解决了开发时候的问题。但是他依然没有解决打包时候的问题。打包的时候还是会全部打包你要编译的东西。

虽然vite很好,但是部署的时候依然痛苦。上线依然是需要等待30分钟的还是得等待30分钟。实际上为什么慢?还不是我们开发的时候文件编译太多了。

现在也有了esbuild,swc-loader。他们只是能解决一部分的问题,但是项目越来越大,最后的问题还是无法解决的。

现在全社区都在想办法解决这个问题,讨论比较多的方案是微前端。可是目前的微前端都是在考虑通过路由的方式去兼容三大框架,但我感觉他们的出发点是不是那里出问题了?你们回忆想想一个问题你见过那个后端微服务,没有注册中心这个说法的?要想打通三大框架的前提不应该是先打通sotre还有service的注册问题吗?

又有点题外话了....回到正题。

vite虽然好,但是他是伴随vue出生的,总感觉会react不太友好。所以我选择了swc-loader来解决bable慢的问题。

image.png

image.png

文件比比较少,但是相比与官方的create-react-app的启动20S快太多了。热更也能控制在300ms内,比vite的还要快一点。因为我开了docker服务,关闭的话估计可以在55ms。

image.png

现在swc-loader在react兼容性还是比较好的,至少使用hooks的我没有感觉到有什么影响。要不next.js也不会直接替换。但是随着你的代码量越来越多,swc-loader处理起来还是非常慢。

其实有那么一个框架,早就给我们提供了解决方法。这个框架就是angular2。模块化加载!我一直在阅读angular2的源码设计和设计原则。现在是想通他们为什么要这么设计,在他们做框架的时候就早已经发现了webpack的问题,他们是想用小单位来优化构建时间。

image.png

思路也很简单,如果你的业务已经做到了一定的规模,你可以把你的业务进行拆分更多模块,最后加载到自己的应用主模块。

原来是因为文件太多了,导致你的构建时间太长。但是你现在想想你把项目拆开了多个服务模块,其实每个模块的代码量并没有多少。你构建的时间单位时间是变少了。

我打个比方:我现在有一个用户模块需要修改。

image.png

实际你会发现,我们只需要编译用户模块的代码就可以了,其他模块是无需修改的!!而且模块你使用npm pack制作本地包,给主模块安装。

你在部署上线的时候只需要使用Jenkins进行两个模块的构建。即可省下你原来需要等待30分钟的打包时间。

模块之间如何通信

当然你会好奇,这么多模块他们到底是什么进行通信的呢?这里就很有玄学了!在后端微服务里面未来保证服务之间的高可用就需要一个注册中心。那么前端我们需要如何管理呢?这个时候我们就需要一个上下文了来管理我们的模块内的私有服务注册器。我们可以把自己的服务注册到上下文当中,其他模块也在这个容器中去相对应的模块进行通信。

image.png

一年前公司请我来编写这个框架,但是签了保密协议我并无权开源代码,只能把我的设计理念分享给大家,除非公司想开源一个版本。

至于思路可以按下面两篇文章进行参考

  1. 模块加载设计思路 React-Router v4之后为什么不用config来管理路由?使用react-router新特性做模块加载吧 - 掘金 (juejin.cn)

  2. 注册通信模块思路 React利用HOC制作自己的模块依赖器,自动注入实现privides重写 - 掘金 (juejin.cn)

部署应该怎么操作

image.png

image.png

好了今天的分享到这里,可能28岁的我。架构思维有限。但是目前来说我感觉这种方式也能解决你构建和开发上的问题。

子模块也能单独开发。主模块只是做集成测试,严格意义来说,就是单语言的微服务ReactCloud

另一种微前端服务架构

其实没有做之前,我还设计另种架构来解决webpack的打包,但是我思考着为什么angular2没有使用。后面发现原来解决不了上下文的问题。我说说之前的思路

使用nginx的方向代理特性进来拆分包的大小,但是后面发现每个模块之间的通信制作的搞得非常复杂。

image.png

你为了要让模块执行的能够兼容起来,你可以需要使用到更多的第三方存储比如cookie等,导致每次跳转页面的时候,做了很多的get,set,init的重复工作。

image.png

但是在结合业务的考虑和扩展的方面考虑,在未来可能使用的东西越来越多。导致我在设计系统的时候会牵扯到使用web socket这些场景跳转如何保证消息的一致性问题,如果使用本地缓存当当是不足我们存储更多的内容,然后有得牵扯到readis使用md5(ip+浏览器版本)对用户的信息进行保存跳转页面初始化。

无疑angular2的设计思路已经领先前端好几个世纪。只不过前端工程化还没出现问题,大多数的前端开发人员没有意思到工程化的重要性。这也是我之前说的三类人,如果你是一个喜欢玩工程设计的请多看angular2

我已经不想和那些水平低的人讨论更多的底层问题。最后让那边还在前端感觉自己刚刚在上的喷子慢慢堆代码吧。