它是什么，为什么我需要它?
让我们从why部分开始，当单页面应用程序启动的时候，大多数应用程序都非常小，并且由一个FE团队管理，一切都很好……
随着时间的推移，应用程序变得越来越大，管理它们的团队也越来越大。没有必要过多地讨论拥有大型代码库和大型团队的问题……
“微前端”这个术语最近被频繁使用，它提供了一个类似于微服务的概念，我们可以将单个前端应用程序拆分为微应用程序，这些微应用程序可以加载到用户浏览器上运行的单个容器应用程序中。每个应用程序都可以有自己的代码库，由一个面向业务的团队管理，他们可以独立地测试和部署他们的微应用程序。
(taken from https://micro-frontends.org/)
虽然这个概念本身听起来很有希望，但是缺乏实际的实现。特别是那些可以应用于现有大型应用程序的应用程序。
选择
一种可能的解决方案是使用良好的旧Iframe，它在封装和独立性方面提供了许多优势，但它是一种旧技术，并且存在严重的规模问题。
除了iframe之外，Web组件这个术语也出现了一段时间。
Web组件是一种解决方案，您可以在其中创建可以独立运行的自定义DOM元素，并提供分离和css封装，虽然这听起来是正确的方向，但Web组件离实际的解决方案还很远。它们更多的是一个概念，其背后的特性，如shadow DOM仍然缺乏完整的浏览器支持。
我们的解决方案
在Outbrain，我们一直面临着大多数资深SPA (单应用)所面临的问题，我们有一个庞大的FE应用程序，有一个庞大的团队来管理它，它变得越来越粗糙。看到在野外没有出色的MFE解决方案，我们决定尝试寻找一个我们自己的解决方案，一个可以在我们现有的echo系统上快速实现的解决方案。
我们定义了几个关键点，我们认为任何解决方案都必须应用MFE。
独立模式
每个微应用都应该能够完全独立运行，所以每个负责给定应用的团队都应该能够独立于其他应用运行。
这意味着每个应用程序应该托管在一个单独的代码基上，并且能够在开发人员的计算机上本地运行，以及在开发和测试环境中运行。
部署
可以独立每个服务部署到任何环境包括生产为了让业主团队的自由而不干扰其他团队工作,如果一个bug修复需要部署到生产在周末没有其他团队应该参与。
测试
在每个微应用程序上独立运行测试，这样一个应用程序中的bug很容易识别，不会反映到其他应用程序上。也就是说，有必要进行一些集成测试来检查应用程序之间的接口，并确保它们没有被破坏，这些测试应该由所有团队监控。
一个到多个
我们希望能够多次使用每个微应用程序，一个微应用程序不应该关心它在哪里运行，只知道它的输入和输出。
运行时分离和封装
重要的是，每个应用程序在运行时环境中都要沙箱化，这样应用程序之间就不会相互干扰，这包括CSS封装、JS命名空间和HTML分离。
常见的资源共享
因为我们不想要加载大型模块,如角,lodash和多次CSS样式的应用程序是很重要的微型应用程序能够共享公共资源,也就是说,我们也希望能够允许他们只封装资源相关,或封装在应用程序资源有不同的版本,例如应用程序使用lodash 3和应用程序B想迁移到lodash 4。我们不希望等到所有的应用程序都迁移之后才能升级。
通讯
需要有一种解耦的方式，让应用程序在不真正了解彼此的情况下彼此通信，只需要通过预定义的接口和API。
向后兼容性
由于我们不打算重写庞大的代码库，所以我们需要一些可以插入到当前系统的东西，以及可以由其他团队管理的逐渐独立的部分。
Web组件
最后,任何解决方案我们应该尽可能一致的web组件的概念,尽管它目前只是一个概念,似乎这就是未来是标题,如果将来任何解决方案出现,将自己与未来这将帮助我们采取的解决方案。
第2部分
在接下来的部分中，我将详细介绍我们是如何实现这一目标的，以及我们是如何通过写作来实现这一目标的。
下一部分的内容包括Angular、Webpack和一些美味的加载器。
原文：https://medium.com/outbrain-engineering/micro-front-ends-doing-it-angular-style-part-1-219c842fd02e
