websocket - MicroFrontends 通过单 channel /websocket 到 MicroService 后端的通信模式

Question

我们目前面临着一些关于集成多个 Web Components 的棘手架构问题将复合网络用户界面中的独立后端服务整合到一个流畅的网络应用程序中。

(可协商的)设计决策有一些限制:

1. 微服务应该服务于它自己的前端(WebComponent)，我们希望使用 HTML Imports 来允许将这样的 WebComponent 包含到复合 UI 中
2. 前端 WebComponent 需要能够从其后端微服务接收实时更新/事件
3. 页面(复合 UI 中使用的 Web 组件的总和)应仅使用一个连接/永久占用的端口与后端通信

我画了一个草图来代表我们的抽象/非技术需求以供进一步讨论:

据我所知，这个问题可以改写为:我们如何

a) 集中沟通进入

b) 在退出时分发通信

两端的单一传输路径。

这两个任务需要在传输路径的两侧解决，例如。后端和前端。

对于后端，我很希望采用BFF模式as not only described by Sam Newman可以满足我们的需求。上面草图的右半部分(后端)可能看起来类似于:

传输路径最好使用标准化网络技术，例如。 https 和 websocket (wss) 用于大多数时候需要的双向通信。我很想了解在网络技术领域具有同等高采用率的替代方案。

对于前端，我们目前缺乏关于先前描述的模式或框架的想法和知识。

棘手的是，多个基本独立的 WebComponents 需要一起找到才能使用 ONE 中央通信路径。例如，如果通过实现一个(大型)Angular 应用程序来实现前端，我们将实现并注入(inject)“BackendConnectorService”(待讨论的名称)并注入(inject)我们的各种组件。

但是由于我们想使用分离的 Web 组件，因此不存在用于共享业务逻辑和依赖项注入(inject)的此类背景层。我们是否应该编写一个专有的 JS 库，如果我们的每个组件还不存在，它将被加载到窗口上下文中，并将用于(按照惯例)与后端通信？

这将大致集成到如下草图中:

我们的应用程序思考/设计是否有误？

对于经过验证的模式/框架的每一个合理想法或提示，我都心存感激。

此外，您对问题和架构的看法可能有助于解决我们目前面临的问题。

Answer 1

对于前端，我会采用您在后端使用的相同方法。创建一个 HTTP 或 WS 网关，前端组件将轮询请求。它将连接到后端 BFF，您在那里解决了所有问题。任何时候您想要交换您的组件、传输或架构，一个都不依赖于另一个。