透过现象看本质: 常见的前端架构风格和案例
|
复制风格常用于网络服务器。浏览器和Node都有Worker的概念，但是一般都只推荐在CPU密集型的场景使用它们，因为浏览器或者NodeJS内置的异步操作已经非常高效。实际上前端应用CPU密集型场景并不多，或者目前阶段不是特别实用。除此之外你还要权衡进程间通信的效率、Worker管理复杂度、异常处理等事情。 有一个典型的CPU密集型的场景，即源文件转译. 典型的例子是CodeSandbox, 它就是利用浏览器的Worker机制来提高源文件的转译性能的:  除了处理CPU密集型任务，对于浏览器来说，Worker也是一个重要的安全机制，用于隔离不安全代码的执行，或者限制访问浏览器DOM相关的东西。小程序抽离逻辑进程的原因之一就是安全性 其他示例：
微内核架构  微内核架构(MicroKernel)又称为"插件架构", 指的是软件的内核相对较小，主要功能和业务逻辑都通过插件形式实现。内核只包含系统运行的最小功能。插件之间相互独立，插件之间的通信，应该降到最低，减少相互依赖。 微内核结构的难点在于建立一套粒度合适的插件协议、以及对插件之间进行适当的隔离和解耦。从而才能保证良好的扩展性、灵活性和可迁移性。 前端领域比较典型的例子是Webpack、Babel、PostCSS以及ESLint, 这些应用需要应对复杂的定制需求，而且这些需求时刻在变，只有微内核架构才能保证灵活和可扩展性。 以Webpack为例。Webpack的核心是一个Compiler，这个Compiler主要功能是集成插件系统、维护模块对象图, 对于模块代码具体编译工作、模块的打包、优化、分析、聚合统统都是基于外部插件完成的. 如上文说的Loader运用了管道模式，负责对源文件进行转译;那Plugin则可以将行为注入到Compiler运行的整个生命周期的钩子中, 完全访问Compiler的当前状态。 Sean Larkin有个演讲: Everything is a plugin! Mastering webpack from the inside out  这里还有一篇文章<微内核架构应用研究>专门写了前端微内核架构模式的一些应用，推荐阅读一下。 微前端 前几天听了代码时间上左耳朵耗子的一期节目, 他介绍得了亚马逊内部有很多小团队，亚马逊网站上一块豆腐块大小的区域可能是一个团队在维护，比如地址选择器、购物车、运达时间计算… 大厂的这种超级项目是怎么协调和维护的呢?这也许就是微前端或者微服务出现的原因吧。 微前端旨在将单体前端分解成更小、更简单的模块，这些模块可以被独立的团队进行开发、测试和部署，最后再组合成一个大型的整体。  微前端下各个应用模块是独立运行、独立开发、独立部署的，相对应的会配备更加自治的团队(一个团队干好一件事情)。微前端的实施还需要有稳固的前端基础设施和研发体系的支撑。 如果你想深入学习微前端架构，建议阅读Phodal的相关文章，还有他的新书《前端架构：从入门到微前端》 组件化架构 组件化开发对现在的我们来说如此自然，就像水对鱼一样。以致于我们忘了组件化也是一种非常重要的架构思想，它的中心思想就是分而治之。按照Wiki上面的定义是：组件化就是基于可复用目的，将一个大的软件系统按照分离关注点的形式，拆分成多个独立的组件，主要目的就是减少耦合. （编辑：辽源站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |