iframe上的微前线
在一家公司中，做出了一个平衡而谨慎的CTO决定，即微前沿应与微服务相提并论，并且它们应在iframe上提供服务。
顺便说一句，顺便说一句，微软提供了Office 360产品，以前它在顶部和侧面菜单中使用了<iframe />。现在，iframe不存在。
微型阵线的原因和前提条件
微型前端的主要优势之一是将整体功能划分为多个团队，能够更精细地进行端到端测试，并且还可以更轻松地分批出售软件（对于盒装解决方案）。
所有可用的应用程序都是React SPA。除了Material UI，React Router v4和胚UI-kit作为npm模块外，它们没有其他共同点。
某些应用程序将以独立版本的形式或作为另一个应用程序的一部分使用和交付。
Microfronts分为大型功能块：
- 应用程序标头。应用之间的路由
- 仪表板应用程序。带有指标和小部件。每个仪表板小部件都必须是相应应用程序的一部分（通过iframe连接）。
- 应用程序本身。其中一些包含彼此的一部分（但没有狂热和递归）
因此，获得了彼此独立的不同释放周期。只要应用程序遵循内部API。
问题＃0。微前沿分离不正确
不幸的是，人们对微前沿的思考还不够深入。一个示例是在线商店。购买按钮和购物车可以分散在很多地方，但它们都是一个微区。作为产品卡的10种变化形式，以及订购过程（其中的帐单和地址）。所有这些都可以是具有各自释放周期的单独微区。
实际上，事实证明应用程序的划分非常粗略。与在线商店类似，这是一个团队制作购物车和结帐页面，而第二团队制作其余部分（包括所有其他页面上的购物车柜台）的时间。同时，每个人都使用相同的业务逻辑，并且该接口在UI-kit或Material-UI库级别被重用。
事实证明，功能应用程序（以绿色和紫色标记）有很多共同点。在这两个应用程序中，业务逻辑的重要部分必须分为一个单独的微前端并使用。实际上，远远没有两个这样的应用程序。总共大约有七个功能应用程序未在适当的级别重用逻辑。
结果，节省了重复使用应用程序的时间。功能重复也保持在较高水平。使用没有iframe的微前端或具有扩展UI工具包中的更复杂逻辑的组件可以解决功能重复的问题。
问题＃1。缺乏流程编排
虽然讨论了有关微服务组织的许多问题。他们将如何彼此通信，通过什么协议，将微面之间的交互过程的组织放到了后面。
为了一劳永逸地解决所有CORS问题，决定安装可处理路由的nginx。因此，每个微区和每个微服务都有其自己的地址，例如： 问题仍然存在，如何在开发模式下测试应用程序？每个应用程序将在不同的端口上提供服务吗？
https://domain.zone/dashboard
https://domain.zone/header
https://domain.zone/app1
https://domain.zone/app2
https://domain.zone/api1
https://domain.zone/api2
这就是“ http-proxy-middleware”软件包的得力之处，可以与CRA一起配置。事实证明，只有一半的前端开发人员能够进行这种设置。当然，这里不能责怪任何人，但是这种问题已经出现，必须从组织上解决。
还需要对所有应用程序进行清晰的版本控制，并说明其功能，可用方法和内部API。这导致了下一个问题：文档。
问题2。缺乏内部API
为了使应用程序彼此之间很好地交互，需要文档。不幸的是，就我们而言，只有微服务才有文档。目光并没有落在微战线上。
对于分散的团队，甚至在考虑人员流动的情况下，这是系统中非常关键的部分。
还需要开发一种用于应用程序之间通信的机制。在这里，`postMessage API`可以挽救或直接访问几乎内置于每个React应用程序-Redux中的另一个。什么不是消息总线？但是稍后会更多。
问题＃3。iframe不够灵活
使用`<iframe />`标签没有任何问题。它是一个功能强大的工具，具有内置的消息总线（postMessage API）和广泛的安全性自定义功能。
但是，在微前沿情况下，<iframe />施加了很多限制。其中之一是无法在页面的多个部分重用一个应用程序。
重用应用程序
以在线商店为例，10个“购买”按钮将创建10个<iframe />，即10个正在运行的React应用程序。没有足够的内存用于此。这是无法按功能将应用程序分成团队的原因之一。
URL不适合作为状态管理
我们都习惯于通过URL路由应用程序。在使用前面板作为独立单元的情况下，这也很方便。例如，当主应用程序的一部分足够连贯以至于可以单独使用时。当然，这不是iframe方法的独特优势，但操作非常简单。
这是一个来自KDPV的具有不同URL的紫色应用程序如何作为独立应用程序运行的示例：
但是，在我们的案例中，使用URL iframe接口切换Microfront的状态原来是不可能的：由于历史API与pushState的不完全集成，Microfront从头开始加载`和响应路由器-获得一个完整的页面刷新。
外部“ iframe”点击处理程序
想象一下要创建一个下拉菜单。如上图：从粉红色菜单。并通过单击空白区域将其关闭。在iframe的情况下，您需要使用条件postMessage API，因为由于窗口对象不同，根本无法识别点击。或者提出全屏放大的iframe元素具有透明背景的技巧。
顺便说一下，调整iframe的大小并对其调整父应用程序也变得更加麻烦和复杂。
奖励问题：Cookie使用不当
这个问题与微观战线没有直接关系，但将其带入了更高的疯狂程度。
决定不仅在令牌中写入授权cookie，而且在应用程序中某些部分的权限的完整列表中也要写入。所有这些都由SHA加密-??? 并转换为base64。
结果，cookie的大小超过了8KB，这是nodejs / nginx的默认值（或Google Chrome中一个cookie记录的大小为2KB），这导致服务器配置更加复杂（如果没有弹出CRA，则无法从此设置开始），以及还需要将此大型加密数据集拆分为较小的Cookie字符串。
这意味着对服务器的每个请求，甚至是要获取“ favicon.ico”或获得可用菜单部分的列表，都配备了一个令人印象深刻的附加标头。
结论。那么如何与微区一起生活呢？
首先，当然，您需要决定是否需要微前沿？通常，以npm模块形式正确配置和丰富的UI-kit可以解决独立发行版和相同外观样式的问题。
- 不要使用iframe。它不会简化工作，而只会增加性能问题，严重限制了将应用程序拆分为多个微领域的能力。将SPA块呈现为特殊保留的标签是一种更为有效的解决方案。
- 制定流程编排：在生产和开发中均如此。当雇用他从现成的模块中铆接接口时，并不是每个开发人员都愿意涉足路由和代理的相关行业。
- 在应用程序之间开发一条消息总线。在单个全局空间（即窗口对象）的情况下，这要容易得多。
- 在界面上创建文档以进行应用程序交互以及它们的启动和配置。