【微前端microfrontends】什么是微前端？

[yayxs]

微前端

我们可能听说过微服务 但到目前为止前端已经不仅仅是前端 ,我们接下来要探讨的就是微前端 (Micro Frontends)。

什么是微前端

历史

在前端的前一阶段，我们还是仅仅切图 然后后端进行套页面。慢慢地慢慢地我们开始进行前后端分离。慢慢的出现三大框架，也是主流的框架。前端还得会PS

那在2016 年时候，被提出，也是和微服务概念 有异曲同工之妙

概念

Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently.

我们可以称：微前端是一种方案，或者策略方法技术。我们可以实现由不同的团队 不同的技术 构建统一化的现代web应用程序

核心思想

• 技术无关
• 代码隔离
• 建立一定的前缀（这里指的是每个小项目的命名空间）

目前项目问题以及期待

问题

一个是路由的问题，一般的TOC 的项目，页面少的话也还说，但是像100+的页面即使是异步加载，也会性能会受到影响

一个就是技术栈的问题，一个小组可能喜欢React 一个小组就是喜欢写Vue ，跨前端技术栈不一样

• 上线慢、频繁
• 框架无法调整
• 工厂巨大理解困难
• 工作混乱，规范和灵活相互矛盾
• 遇到bug 大海捞针
• 巨石应用

优势与挑战

即使我们不在自己的项目实践微前端，但是在面试 或者一些其他的场景中，难免会提及，就像是TypeScript 一样，凡是流行的，就是大家关注的。我们可能会想得到这样一个效果

• 服务发现

• 运行隔离

• 环境一致

• 能够增量的方式升级，更新甚至重写前端的代码

  • 大型的前端项目一定会超过几年的迭代。我们还时不时的为客户提供新功能，这样不会影响整体

• 独立部署

  • 微前端的独立部署能力也是十分关键的，正是因为有独立部署的能力，就降低了无关的风险。不管代码托管到什么位置
  • 我们应该能够在不考虑其他代码库的情况下测试部署等

  

那么既然有许多优势，我们实际操作起来又会遇到什么问题呢？比如说像是js代码的隔离 css样式的冲突 按需加载资源 。一些冲突我们可想而知，是再所难免的。为什么这样说，因为一个简单的项目由不同的开发人员参与难免还会出现命名的冲突。

我们会在一些大型成熟的开发框架中，看到渐进式 为什么大家大家那么看重。但在实际的操作中，总是找不到一个合适的地方将功能集成到现有的代码中。我们可以想一想自己日常工作的项目中，是不是具有强耦合。正是因为项目的复杂性让我们每个人都在相互踩脚。不够“干净” 。那面向B端的客户，更会在不同的场景提出不同的需求，开发人员改起来代码瑟瑟发抖

方案思路

建立整合的时间

我们想到的一种方法是将每一个微前端发布一个单独的包，那我们的package.json

{
  "name": "@root/container",
  "version": "1.0.0",
  "description": "A weiqianduan web app",
  "dependencies": {
    "@root/part1": "^1.2.3",
    "@root/part2": "^4.5.6",
    "@root/part3": "^7.8.9"
  }
}

但是不建议这种思路，我们应该找到一种在运行时，并不是在构建时集成的微前端方法

不起眼的iframe

没错我们可以通过iframe 将应用程序在“浏览器” 中组合在一起，一方面可以轻松的实现子页面的独立；另一方面样式和全局变量互不干扰。并且还有很高的隔离度

相关链接

• https://micro-frontends.org/
• https://martinfowler.com/articles/micro-frontends.html