微型前端架构建议 [英] Micro frontend architecture advice
问题描述
我们希望在单个页面应用程序下呈现多个Web应用程序. 我们正在寻找一种可以使用的微前端架构/框架. 正如我们所看到的，这些是我们的实施选项:
We have several web applications that we wish to present under one single page application. We are looking for a micro-frontend architecture/framework to use. As we see it, these are our options for implementation:
- 使用单一spa开源框架: https://github.com/CanopyTax/single-spa
- 使用Iframe(友好iframe)托管应用程序(外壳程序)并根据当前url加载每个应用程序.
- 编写我们自己的Javascript框架
- 其他?
- Using the single-spa open source framework: https://github.com/CanopyTax/single-spa
- Using Iframes (friendly Iframes) the hosting application (the shell) and loading each application according to the current url.
- Writing our own Javascript framework
- Other?
当前状态是一个整体式FE应用程序，该应用程序将另一个子应用程序用作内部第3方程序包. 对于我们来说，这种方法是不可扩展的，因为托管应用程序正在一起构建所有产品，并且没有真正分开的东西.
The current state is a monolith FE application that consumes the other child-application as internal 3rd party packages. This approach is not scalable for us, because the hosting application is building all the products together, and nothing is really separated.
我们的要求是微前端的通常要求: 1.自主开发- 每个团队都可以选择自己的框架并构建自己的产品，而与其他产品无关.
Our requirements are the usual requirements for micro-frontend: 1. Independent development - Each team can choose their own frameworks and build their products regardless the other products.
-
独立部署- 每个应用程序都可以在生产中进行升级，而无需停机，也不会干扰其他应用程序.
Independent deployment - Each application can be upgraded in production without downtime and without interfering the other applications.
共享组件- 我们在应用程序中使用了Angular4，并且我们已经编写了一个专有的第三方库(共享的组件和逻辑)，应该在所有产品之间共享它们以提供相似的外观.
Shared components - We're using Angular4 in our applications, and we have a proprietary 3rd party library (shared components and logic) that we've already wrote that should be shared among all of the products for similar look and feel.
我们希望能够升级每个应用程序的框架(Angular，RXjs，Typescript等以及我们专有的组件库)，而无需关心其他应用程序.
We would like to have the ability to upgrade each application's framework (Angular, RXjs, Typescript etc and also for our proprietary component library) without caring about the other applications.
我们尝试使用Single-Spa框架，但是存在一些问题，我们目前正在思考是否这是适合我们的方法，还是应该尝试其他方法.
We tried to use the single-spa framework but we have some issues and we are currently found our-self thinking if this is the right approach for us, or should we try a different approach.
我们使用单一温泉浴场的问题是: 1.资产装载是有问题的. (我们必须在主机应用程序的根文件夹上拥有资产文件，并且切换到另一个应用程序时，我们会遭受资产冲突的困扰). 2.我们仍然不知道如何为所有应用程序处理全局样式(我们使用sass进行样式设置，必须将其与每个应用程序的本地样式一起使用) 3.升级角度框架(或所有其他框架)对于一个应用程序是不可能的，它是全部或全部(因为我们只有一个角度的实例). 4.我们必须在托管应用程序(外壳)的另一端实施不同的捆绑开发.
The issues we have using the single-spa are: 1. Assets loading is problematic. (We must have the assets files on the root folder of the hosting application, and we suffer from assets conflicts when switching to another application). 2. We still don't know how to handle global styling for all applications (We use sass for styling and it must be complied together with the local styles for each application) 3. Upgrade angular framework (or all other frameworks) is not possible for one application, it's all or nothing (since we have one instance of angular). 4. We have to implement a different bundling for development other side the hosting application (the shell).
考虑使用iframe(使用友好的iframe)解决方案时，我们可以看到所有子应用程序之间的完全隔离，并倾向于认为这对我们来说是更合适的方法.
When we think about the Iframe (using friendly Iframe) solution, we visualize a full separation between all child-application, and tend to believe this is a more suitable approach for us.
使用iframe是否有陷阱?
Are there any pitfalls for using Iframes?
谢谢， 丹尼尔
推荐答案
我想在前端微服务的可能体系结构解决方案主题中加2¢:
I would like to add my 2¢ to the topic of possible architectural solutions for frontend's microservices:
- OpenTable使用的OpenComponents – https://github.com/opentable/oc
- Zalando的马赛克– https://www.mosaic9.org/
- OpenComponents used by OpenTable – https://github.com/opentable/oc
- Mosaic by Zalando – https://www.mosaic9.org/
希望您发现它们有用.
这篇关于微型前端架构建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
