微前端是一种可以追溯到多年的新趋势。配备了应对挑战的新方法和解决方案，他们现在正慢慢进入主流。不幸的是，许多明显的误解使许多人难以理解微抗议。简而言之，微前端就是将微服务的一些好处带入前端。更重要的是，不要忘记微服务没有灵丹妙药。提示：要在微前端或任何其他项目之间共享React/Angular/Vue组件，请使用像bit这样的工具。Bits允许您从任何代码库中“收获”组件，并将它们与bits组合成一个bits集合。它使您的组件可供您的团队使用，以便在任何存储库中使用和开发。使用它来优化协作、加速开发并保持一致的UI。>示例：在bit.dev中搜索共享的React组件误解然而，虽然本文也可以总结一些选择微前端的原因，但我想列出我在过去几个月听到的最常见的误解。让我们从显而易见的开始。1.微前端需要JavaScript。当然，目前市面上的微前端解决方案很多都是JavaScript框架。但这怎么会错呢？JavaScript不再是可选的。每个人都想要高度交互的体验，而JS在提供这些体验方面发挥着重要作用。除了给定的优点外，还应考虑快速加载时间、可访问的Web应用程序和其他因素。因此，很多JavaScript框架都提供了渲染图像的能力。最后，这导致不仅能够在客户端拼接，而且能够在服务器上准备所有内容。根据所需的性能（即第一个有意义的初始时间），这个选项听起来不错。请记住，后端渲染有其自身的挑战。然而，即使在没有JavaScript解决方案的情况下使用同构渲染，我们的状态也很好。如果我们想在没有JavaScript的情况下构建微前端状态，我们绝对可以做到。存在许多模式，其中大部分不需要JavaScript。考虑一种“较旧”的模式：使用我听到你笑了吗？好吧，回到过去，人们今天尝试做的一些拆分是允许的（更多内容见下文）。一个页面（可能由另一个服务呈现？）负责菜单，另一个页面负责标题。今天我们使用更灵活（并且仍然受到积极支持）的元素。它们提供了一些不错的功能——最重要的是，它们将不同的微前端彼此隔离开来。仍然可以通过PostMessage进行通信。2.微前端只为客户端服务在JavaScript的误解之后，这是一个更上一层楼。当然，有多种技术可以在客户端实现微前端，但实际上，我们甚至不需要任何类似的东西来获得微前端。微前端可以像服务器端的“包含”一样简单。这通过包括EdgeSide在内的先进技术变得更加强大。如果我们要排除微店段功能实现的场景，那么简单的链接也行。最后，微存档解决方案也可以像微型、解耦的服务器端渲染器一样简单。每个渲染器可以小到一个页面。下图说明了反向代理中发生的更高级的拼接。>通过反向代理JavaScript的服务器端拼接当然可能有几个优点，但它仍然高度依赖于你试图用微前端解决的问题。根据您的需要，服务器端解决方案可能仍然是最佳（或至少更好）的选择。3.应该使用多个框架在几乎所有关于微前端的教程中，不同的部分不仅由不同的团队开发，而且使用不同的技术开发。这是假的。是的，不同的微前端应该与不同的技术一起使用，但是，这不应该是目标。我们也不会仅仅为了拥有真正的拼凑而成（或者我们应该在后端说“混乱”）而做微服务。如果我们使用多种技术，那只是因为我们获得了特定的优势。我们的目标应该始终是某种团结。做到这一点的最好方法是想象一个绿色领域：那我们要做什么？如果答案是“使用单一框架”，那么我们就走在了正确的轨道上。现在，从长远来看，多个框架可能会在您的应用程序中变得明显。这可能是由于遗产。这可能很方便。这可能是一个概念证明。不管是什么原因：能够适应这种情况仍然很好，但它永远不应该是理想的状态。无论您的微前端框架有多高效——使用多个框架总是会带来不可忽略的成本。不仅初始渲染需要更长的时间，而且内存消耗也朝着错误的方向迈出了一步。不能使用便利模型（例如，框架的模式库）。需要进一步重复。最后，错误的错误、不一致的行为和应用程序的感知响应能力都会受到影响。4.按技术组件拆分一般来说，这没有多大意义。我还没有看到服务器在一个服务中而API在另一个服务中的微服务后端。通常，服务由多个层组成。有时会使用诸如sidecars之类的技术，尽管某些技术（例如日志记录）肯定会被引入公共服务。此外，服务内的通用编程技术也被考虑在内。对于微前端，这是一样的。为什么微前端只能是菜单？不就是一个菜单吗，每个微前端是不是都相应的填充了？拆分应该根据业务需求来完成，而不是根据技术决策来完成。如果您读过领域驱动设计，您就会知道它是关于定义所有这些领域的——而且这个定义与任何技术要求无关。考虑以下拆分：>按布局分解为微前端这些是技术组件。这与微前端无关。在真正的微前端应用程序中，屏幕可能更喜欢以下内容：>按域分解为微前端这里绘制的拼接更复杂，但这是一个合理的微前端应用程序应该给你的！5.你不应该分享任何东西不。您应该出于有意义的原因分享和分享。您绝对不会共享所有内容（请参阅下一点）。但要保持一致，您需要至少共享一套原则。现在，无论是通过共享库、共享URL，还是仅通过您在构建或设计应用程序时使用的文档，都无关紧要。对于微服务，这种“无共享”架构如下图所示。>“Sharenothing”架构应用于浏览器中的微服务，这将导致使用，因为目前没有其他方法可以防止资源泄漏。影子DOMCSS可以隔离，但脚本级别仍然可以触及一切。即使我们想遵循模式，我们也会遇到麻烦。复制资源只是为了让简单的组件保持活动状态会削弱感知性能。诚然，更深入的共享（例如使用附加到DOM的共享库）可能会出现问题。但是，另一方面，松散的共享（例如，仅指定基本设计元素的文档）会造成不一致。6.你应该绝对分享一切。如果那是想法，那么单体应用更有意义。性能明智这可能已经是一个问题。我们懒得加载什么？我们可以删除一些东西吗？但真正的问题是依赖管理。没有什么可更新的，因为它可能会破坏某些东西。共享部分的美是一致的保证。现在，如果我们共享所有内容，我们就会引入复杂性以保持一致性。但是无法保持这种一致性，因为复杂性会在每个角落引入错误。这个问题的根源在于“依赖地狱”。下图简要说明。>进入依赖地狱简而言之，如果一切都依赖于一切，我们就会遇到依赖问题。仅仅更新一个盒子就会对整个系统产生影响。持续？真的。简单的？绝对不。7.微前端仅限于网站，为什么？确实，到目前为止我们主要接触的是网络，但是概念和想法可以带到??任何类型的应用程序（移动应用程序、客户端应用程序……，甚至是CLI工具）。在我看来，微前端只是“插件架构”的奇特新词。现在如何设计插件接口以及使用插件运行应用程序需要什么是另一回事。下图显示了一个相当通用的插件架构。感谢OmarElgabry。>通用插件架构没有运行位置的概念。它适用于手机。它可以在Windows上运行。它可以在服务器上运行。8.微前端需要庞大的团队，为什么？如果解决方案非常复杂，那么我肯定会寻找更简单的方法。有些问题需要复杂的解决方案，但通常一个好的解决方案是一个简单的解决方案。根据情况，甚至可能不需要分布式团队。分布式团队是微前端极客首先有意义的原因之一，但它们并不是唯一的原因。另一个很好的理由是特征的粒度。如果您从业务角度来看微前端，那么您会发现能够打开和关闭特定功能是很有意义的。针对不同的市场，可以使用不同的微前端。退回到简单的特权级别是有道理的。无需编写代码来根据条件打开或关闭某些东西。所有这些都留给了公共层，可以根据（可能是动态的）条件激活或停用公共层。这种方式不能（或不应该）使用，也不能通过。虽然这不应该是一层保护，但它肯定是一层便利（和性能）。用户不会感到困惑，因为他们所看到的就是他们能做什么。他们看不到功能。该函数甚至没有被传递，所以没有字节被浪费在不可用的代码上。9.无法调试微前端我担心这部分是正确的，但总的来说，它不应该而且（剧透！）也不一定是。对于任何类型的实现（或适合该论点的底层架构），开发体验都可能会瘫痪。唯一的战斗方式是开发者——第一。实施的第一条规则应该是：调试和开发。采用标准工具。一些微前端框架根本不支持这一点。有些需要在线连接、专用环境、多种服务……这不应该是常态。这绝对不是常态。10.微服务需要微前端（反之亦然）虽然Conjunctival的模块化后端可能是解耦前端的良好基础，但通常情况并非如此。拥有一个需要模块化前端的单一后端是完全可行的，例如，允许简化的个性化可能与授权、权限和市场相结合。事实上，从同样的意义上讲，微服务后端不仅仅是将类似模式应用于前端的标准。许多微服务后端由单一用途的应用程序操作，这些应用程序不会增加功能，而只会增加外观。11.微前端需要一个单一的代码存储库我已经多次阅读它来创建一个可以利用MonoRepo的微状态解决方案，最好使用像Lerna这样的工具。我不相信。当然，单一代码库有一些优点，但它们也有一定的缺点。尽管有微框架需要联合CI/CD构建。联合CI/CD构建的要求通常会产生一个单一的代码存储库，因为它一开始就更容易设置。但对我来说——这是重新包装的单体。如果你在单一代码库中有一个联合版本，那么首先可以标记两个非常重要的因素来让微前端更有趣：独立部署独立开发不管怎样，如果你看到需要单一代码库的微前端解决方法：运行。对于所有等待已久的分布式系统的问题，精心设计的单体可能会更好。monorepos/lerna的一个很好的替代品是bits。位允许您在存储库中的组件上进行协作-使团队能够独立贡献功能。结论微前端仍然不适合所有人。我不相信微前端是未来，但我也是其中的积极分子，在未来发挥着重要作用。
