检查哪种架构适合您的需求

> Photo by Jonny Caspari on Unsplash

我一直在工作和研究微前端，我现在有足够的信息来与世界分享。随着项目更大，更大，很难维护和合作这些项目。随着项目变得更大的，它们的构建时间增加，单位测试增加，团队规模增加，几乎一切都变得更大，到达我们无法维护的阶段。

因此，为团队的性能提供较小的项目和较小的团队总是更好的，并将产品更快地向最终用户提供。但是，有时您的产品或您的应用程序具有如此多的功能，维护较小的团队和项目是从手中的。您可以为每个功能进行单独的团队，但管理团队，将所有功能合并到一个回购中，并解决冲突等。所有这些都是我们可以避免微观前端的繁琐任务。

微前端不是框架或库。这是我们可以将我们的FAT应用程序分为较小和可维护的应用程序并设计某种编排的方法，以便将这些应用程序放在浏览器窗口中，以便最终用户看到一个应用程序。我们可以实施六种不同的方法。以下是不管技术如何做到这一点的方法。我将为每个人提供单独的帖子，全面实施。我们现在将刚刚通过这些的高级架构。

Webpack Module Federation
Iframes
Through NGINX
Web Components
React Component Libraries
Monorepos
Customized Orchestrator

WebPack模块联合会

多个单独的构建应形成单个应用程序。这些单独的构建不应彼此之间有依赖关系，因此可以单独开发和部署它们。

> Webpack Module Federation

有本地和远程模块。本地模块只不过是当前构建模块和远程构建的构建是应导入当前应用程序或构建的构建。

每个构建都充当容器，也消耗了其他构造作为容器。这样，每个构建都能够通过从容器加载它来访问任何其他公开的模块。可以嵌套一个容器。容器可以使用来自其他容器的模块。容器之间的循环依赖性也是可能的。

你可以在这里找到更多。

iframes.

iframes是可以嵌入另一个HTML文档中的HTML文档。这是iframe的一个例子。您可以在IFRAME标记中放置您想要的任何源，并且基于父文档中帧的宽度和高度呈现。

html>
<html>
<body>

<iframe src="http://localhost:3000" width="600" height="900">
  <p>Your browser does not support iframes.p>
iframe>

<iframe src="http://localhost:3001" width="600" height="900">
  <p>Your browser does not support iframes.p>
iframe>

body>
html>

在上面的示例中，我分别在端口3000和3001上运行两个React应用，并且是上述文档中定义的IFRAMES的源。当您在浏览器中加载此时，您可以在与下面的窗口中看到两个并排。这是一个简单的例子，但我将在即将到来的帖子中发布比这更好的榜样。

> Micro Frontends with Iframes

这种方法更好适合项目，其中所有功能都驻留在同一页面上而没有任何导航，并且通过窗口对象发生通信。

通过nginx.

当项目中涉及导航和路由时，上述方法不适合。你可以拥有这个，但应该有另一个用于导航的shell项目。nginx可用作Web服务器或反向代理以提供静态内容。我们可以使用nginx基于上下文路径路由相应的微服务程序。如果我们查看下图，我们可以在介于介于上下文路径或路由中使用nginx Web服务器，例如，/用户加载微用户，客户负载微观客户，等等。

> NGINX routing different apps based on context path

这是示例nginx配置文件。我们为每个微前端定义块指令位置，并根据位置路径或上下文根加载适当的应用程序。

worker_processes 4;

events { worker_connections 1024; }

http {
    server {
        listen 80;
        root  /usr/share/nginx/html;
        include /etc/nginx/mime.types;

        location /customers {
            try_files $uri customers/index.html;
        }
         
        location /users {
            try_files $uri users/index.html;
        }
        
        location /admins {
            try_files $uri admins/index.html;
        }
    }
}

这种方法更好地适合在有导航或路由的项目中涉及，并且当应用程序基于该功能分为多个应用程序时。通过反应 – Redux商店和本地存储器发生，如下图所示。当您从一个应用程序从一个应用程序到另一个应用程序，所有应用程序都通过某种状态管理工具和本地存储传输。

> Communication between Micro Frontends

这种方法的缺点是，当我们每次都有页面刷新时切换应用程序时。您可以在每个应用程序中维护一些共享组件，例如标题和页脚以保持相同的布局。

Web组件

Web组件是不同技术的组合，允许您在Web上创建可重用组件。它实际上促进了干燥的原则。它主要由三种技术自定义元素组成，允许您创建自定义元素，这些元素可以在网页上使用何处使用，允许您在除了提供封装的主DOM之外的单独DOM中运行代码，HTML模板这允许您编写可以多次使用的标记模板。您可以在此处获取更多信息。

> Micro Frontends with web components

这是自定义组件的示例。通过这种方法，我们可以将每个微应用程序转换为自定义组件，并在页面上相应地放置它。

<my-message message="Hello, How are you!!">my-message>

所有浏览器都不支持这些Web组件。您需要为不受支持的版本添加PolyFills。

React组件库

在这种方法中，每个微前端都可以是可以将作为节点模块推向某些私有存储库的反应库。我们有一个shell应用程序，可以在懒惰的加载（如果是Angular）或动态导入的情况下，我们需要拉回该库。

如果您查看下面的图表，有三种微前端应用程序可以转换为三个库并被推入存储库。

> Micro Frontends with React Libraries

我们可以将我们的项目推按照Node模块，其中CommandNPM Push App1we可以使用如下的动态导入导入这些库。

import Customers from \'Customers\'

export const App = () => {
    return(
        <div className="header">
            <Customer />
        div>
    )
}

由于所有单个库最终在同一项目或应用程序中最终结束，但通信不是在这里的问题。

MONOREPO

MONOREPO是一种软件策略，您可以在一个repo下放置多个相关项目。通过这种方式，我们不必将共享代码推送以将repo分开作为库或模块，并将其拉用于使用。

如果您查看下面的图表，我们还有一个MONOREPO，其中包含所有项目和共享代码。通过这种方式，我们不必为可共享代码创建任何单独的库。所有共享代码和实际项目都在相同的回购中。

> Micro Frontends With Monorepos

每个开发人员都必须检查整个仓库，即使他只需要一个或两个文件夹。这种方法可以难以定义管道，因为所有项目都生活在同一次数中。

自定义编排

我们定义了纯javascript文件，以协调这些微程的整个工作流程。所有单独项目都已独立部署。Orchestrator可以根据URL加载每个项目。

> Micro Frontends with Customized Orchestrator

您可以在Orchestrator中定义一些全局命名空间和对象（此处的某些_system.js）进行通信。这些全局对象可用于所有项目，以便您可以在应用程序之间发送数据。

结论

随着应用程序变得更大，更大，很难开发，部署和维护这些应用程序。微型前端使其更容易且更快，但这不是每个问题的解决方案。您需要分析您的项目并选择上面的一个架构并实现它。微型前端应该让你的生活更容易地狱。所以，在实现这方面之前才能三思而后行。

内容出处：，

声明：本网站所收集的部分公开资料来源于互联网，转载的目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。如果您发现网站上有侵犯您的知识产权的作品，请与我们取得联系，我们会及时修改或删除。文章链接：http://www.yixao.com/surface/22812.html