详解微前端(3)

发布时间：2021-04-17 来源：网络整理

小中大

字号：

这是相当标准的服务器端组成。我们之所以可以称其为微后端，是因为我们以这么的形式分拆了我们的代码，使得每位代码代表一个独立的领域概念，可以由一个独立的团队交付。此处未显示的是那些HTML文件怎么最终储存在Web服务器上，但是假定他们各自具备自己的布署管线，这让我们可以将修改布署至一个页面上而不会影响或考虑其他页面。

为了荣获更大的独立性，可以有一个单独的服务器负责渲染跟服务每位微后端，其中一个服务器坐落后端，向其他服务器发出恳求。通过仔细地缓存响应，可以在不影响推迟的状况下完成此操作。

详解微前端

我们有时听到的一种方式是将每位微后端公布为一个包，并使容器应用程序将他们全部作为库依赖项包含在内。这是package.json样例应用程序的容器外形：

{
  "name": "@feed-me/container",
  "version": "1.0.0",
  "description": "A food delivery web app",
  "dependencies": {
    "@feed-me/browse-restaurants": "^1.2.3",
    "@feed-me/order-food": "^4.5.6",
    "@feed-me/user-profile": "^7.8.9"
  }
}

起初，这也许是有道理的。像以往一样，它会形成一个可布署的Javascript捆绑包，从而让我们就能从各类应用程序中删掉常见的依赖项。但是，这种方式意味着我们应当再次编译并公布每位微后端，才能公布对产品任何单个部份的修改。就像微服务一样，我们早已听到了这么难办的公布过程所造成的伤痛，因此我们强烈建议不要使用这些微后端步骤。

解决了将我们的应用程序界定为可以独立开发跟检测的离散代码库的所有麻烦，让我们不要在公布阶段再次引进所有这种耦合。我们应当找到一种在运行时而不是建立时集成微后端的步骤。

通过iframe进行运行时集成

不起眼的iframe是在浏览器上将应用程序组合在一起的最简略办法之一。从本质上讲，iframe可以轻松地从独立的子页面中建立页面。在款式跟全局变量互不干扰方面，它们还提供了挺好的隔离度。

<html>
  <head>
    <title>Feed me!title>
  head>
  <body>
    <h1>Welcome to Feed me!h1>
    <iframe id="micro-frontend-container">iframe>
    <script type="text/javascript">
      const microFrontendsByRoute = {
        '/': 'https://browse.example.com/index.html',
        '/order-food': 'https://order.example.com/index.html',
        '/user-profile': 'https://profile.example.com/index.html',
      };
      const iframe = document.getElementById('micro-frontend-container');
      iframe.src = microFrontendsByRoute[window.location.pathname];
    script>
  body>
html>

就像使用服务器端include选项一样，从iframe中建立页面并不是一项新技术，也许虽然并不这么令人激动。但是，如果我们再次考量上面列举的微后端的主要优势，则只要我们慎重地界定应用程序跟成立团队的形式，iframe便太适于。

我们常常见到很多人不甘愿选择iframe。尽管这些不甘愿虽然是由直觉导致的，即iframe有点“讨厌”，但人们还是有一些挺好的理由使人们避开使用他们。上面提及的容易隔离确实会使他们不如其他选项灵活。在应用程序的不同部份之间构建集成或许太困难，因此他们会使路由，历史记录跟深层链接显得格外复杂，并且给让页面完全响应带给了一些额外的挑战。

通过JavaScript运行时集成

我们将描述的下一种方式或许是最灵活的一种，也是我们看见的团队选用速率最高的一种方式。每个微后端都使用

3页:

2

3