什么是微型前端，甚至有必要使用它们

Micro-frontend architecture is a type of architecture where a web application is considered as a composition of features that are owned by separate individual teams. This approach is best suited for complex applications because over time the application tends to grow a bit messy and difficult to maintain.

微前端架构是一种架构类型，其中Web应用程序被视为由独立的各个团队拥有的功能的组合。 这种方法最适合于复杂的应用程序，因为随着时间的流逝，该应用程序会变得有些混乱并且难以维护。

Before we dive into why should we use them, let’s first look into the basic types of architectures used.

在深入探讨为什么要使用它们之前，让我们首先研究所使用架构的基本类型。

使用的建筑模式的基本类型 (Basic Types of Architectural Patterns Used)

• Monolith — In this type of architecture, programmers usually are full-stack developers. They tend to work on both the front end as well as the back end.

  Monolith-在这种类型的体系结构中，程序员通常是全栈开发人员。 它们倾向于同时在前端和后端工作。

• FE/BE — Here there’s a separate group of programmers who look into front-end development, often known as front-end developers/engineers. The other group, who work on the back-end and on databases, are known as back-end developers/engineers.

  FE / BE —这里有一个单独的程序员小组，他们致力于前端开发，通常被称为前端开发人员/工程师。 在后端和数据库上工作的另一组称为后端开发人员/工程师。

• Microservices — Microservices are an architectural style in which applications are decomposed into loosely coupled services, and there are particular teams looking into each service since the logic is too complex and it has to be fine-grained for ease of use.

  微服务 —微服务是一种体系结构样式，其中应用程序被分解为松耦合的服务，并且由于逻辑过于复杂并且必须细粒度以易于使用，因此有特定的团队在研究每种服务。

• Micro frontends — The server logic tends to get more complex. These days even the front-end teams need to have a similar approach as the application tends to grow. In simple terms, these are microservices for the front end.

  微型前端 -服务器逻辑趋于变得更加复杂。 这些天，即使前端团队也需要采用类似的方法，因为应用程序趋于增长。 简单来说，这些是前端的微服务。

选择此方法的主要优势 (Key Advantages of Choosing This Approach)

• Independent teams — Each team can work independently of other teams, as there’s no dependency between teams. The entire team is responsible for developing a set of features, including developing, testing, and the deployment process.

  独立的团队 -每个团队可以独立于其他团队工作，因为团队之间没有依赖性。 整个团队负责开发一系列功能，包括开发，测试和部署过程。

• Technology agnosticism — Each team can use their own technology regardless of what other teams use. Say one team can use React, the other can use Angular, the other can use vanilla JS, and so on.

  技术不可知论性 —每个团队都可以使用自己的技术，而不管其他团队使用什么。 假设一个团队可以使用React，另一个可以使用Angular，另一个可以使用Vanilla JS，依此类推。

• Easy testing — Testing becomes fairly simple, even for a very small change, as we don’t have to go and test the entire application — rather we need to test only the team’s module.

  简单的测试 -测试变得相当简单，即使只是很小的改动，因为我们不必去测试整个应用程序-而是我们只需要测试团队的模块。

• Better maintenance — By using this approach, it’s very easy to maintain the application code as it’s easy to deploy in small parts, and you also have shortened build times.

  更好的维护 -使用这种方法，维护应用程序代码非常容易，因为它易于部署在较小的部分中，并且还缩短了构建时间。

用于实现微型前端的流行技术 (Popular Techniques Used to Implement Micro Frontends)

• Meta frameworks — There are a lot of frameworks, one of which is a single single-page application (SPA). This framework lets you combine multiple JavaScript frameworks/libraries on runtime without refreshing the page.

  元框架 -有很多框架，其中一个是单个单页应用程序(SPA)。 该框架使您可以在运行时结合多个JavaScript框架/库，而无需刷新页面。

• Multiple SPAs on different URLs —This is by far the simplest way of having multiple micro frontends — having separate SPAs rendered when visiting different URLs. The applications use npm components for shared functionality.

  不同URL上的多个SPA-这是迄今为止拥有多个微型前端的最简单方法-访问不同URL时呈现单独的SPA。 应用程序使用npm组件来共享功能。

• iFrames — Here the applications use iFrames to share functionality. iFrames share APIs exposed by their parent window — e.g., the Window.postMessage API can be used to coordinate between micro frontends.

  iFrame —在这里，应用程序使用iFrame共享功能。 iFrame共享其父窗口公开的API，例如，Window.postMessage API可用于在微前端之间进行协调。

• Web components — In this approach, we use a JavaScript wrapper to turn Angular/React or any other component into web components and serve them next to each other.

  Web组件 —通过这种方法，我们使用JavaScript包装器将Angular / React或任何其他组件转换为Web组件，并将它们彼此相邻地提供。

我什么时候应该选择这种方法？ (When Should I Choose This Approach?)

The answer is fairly simple. It relies on how complex your application is. If you think your application is simple, then you can stick with a monolithic approach.

答案很简单。 它取决于应用程序的复杂程度。 如果您认为您的应用程序很简单，则可以坚持采用整体方法。

But if you’re building a large application, if you’re working with a large amount of people/teams, or if you use microservices as your back-end architecture, then choosing this micro-frontend approach is very beneficial.

但是，如果您要构建大型应用程序，与大量人员/团队合作，或者使用微服务作为后端体系结构，那么选择这种微前端方法将非常有益。

结论 (Conclusion)

There are plenty of ways to approach micro frontends these days. I’d recommend you check a variety of patterns and solutions before you start implementing this approach. There isn’t any standard as of today for implementing micro frontends. By choosing this approach you’ll definitely have a lot of advantages when compared to the monolithic approach.

如今，有很多方法可以处理微型前端。 我建议您在开始实施此方法之前，先检查各种模式和解决方案。 到目前为止，尚无任何实现微型前端的标准。 与整体方法相比，通过选择这种方法，您肯定会具有很多优势。

I hope this article gave you a brief idea about micro frontends. Thanks for reading!

我希望本文能为您简要介绍微前端。 谢谢阅读！

翻译自: https://medium.com/better-programming/what-are-micro-frontends-is-it-even-necessary-to-use-them-f1393d65ef2f