Originally written: Micro Frontends
Originally written by Cam Jackson
The Nuggets translation Project
Permanent link to this article: github.com/xitu/gold-m…
Translator: Jenniferyingni
Proofread by: Stevens1995, Baddyo
It’s not easy to do front-end development well, but it’s even harder to scale it up so that multiple teams can work on a large, complex product. This article describes the trend to break down large front-end projects into many small, manageable parts, and discusses how this architecture can improve the effectiveness and efficiency of front-end code teams. In addition to discussing the various benefits and costs, we’ll look at some of the implementation options available and delve into a complete sample application that applies the technology.
In recent years, microservices have become very popular, and many organizations use this architectural style to avoid the limitations of a monolithic back end. There have been many articles written about how to adopt a similar style in server-side software, but many companies still struggle with single front-end codebase.
Perhaps you want to build a progressive or responsive Web application, but can’t find a way to incorporate these features into your existing code. Maybe you want to use the new features of JavaScript (or some other language that can be compiled to JavaScript), but you can’t add the new build tools to your project’s existing build process. Or maybe you just want to scale up your development so that multiple teams can work on a project at the same time, but the coupling and complexity of the existing monolithic architecture means that the code everyone is responsible for will inevitably overlap. These are real issues that can negatively impact your ability to effectively provide quality service to your customers.
More recently, we have focused more and more on the overall architecture and organizational structure required for complex modern Web development. Notably, we see a pattern of breaking up the whole front end into small, simple chunks. These blocks can be developed, tested, and deployed independently, while still coming together as a single product to the customer. We call this technology a microfront end and we define it as:
An architectural style that aggregates small, independently deliverable front-end applications into a single entity
In the November 2016 Issue of ThoughtWorks Technology Radar, we classified the microfront-end as an evaluation grade. It was later upgraded to experimental status and finally to adoption status, which meant that we viewed the microfront end as a proven approach that should be adopted in the right context.
Figure 1: The micro front end has been mentioned a lot on the technical radar.
The main advantages of using a micro front end are:
-
A code base that is small, easy to piece together, and easy to maintain
-
More scalable, decoupled and independent teams
-
It is easier to upgrade, update, and even rewrite parts of the front end in an incremental manner than before
It is no coincidence that the advantages listed above are the same as those of microservices.
Of course, “there’s no such thing as a free lunch” applies to software architectures as well, and a few small front-end implementations can lead to duplication of dependencies, increasing the volume of dependencies that users need to download. In addition, the dramatic increase in team independence can lead to differences in team styles. Nonetheless, we believe that these are manageable risks and that the benefits of using a microfront end far outweigh the costs.
advantages
We will focus on the new properties of the microfront and the benefits they provide, rather than defining the microfront in terms of specific technologies or implementation details.
The incremental upgrade
For many teams, this is the initial reason to embark on the micro front end journey. The old, bulky front-end singleunit model is held back by an outdated technology stack or the quality of rushed code to the point where it’s tempting to overwrite it. To avoid the risk of a complete rewrite, we prefer to renovate older applications gradually, while continuing to provide new functionality to our customers without impact.
This often requires a microfront-end architecture. Once one team is able to consistently add new features and make little change to the whole, other teams will follow suit. Existing code still needs to be maintained, and in some cases it may be necessary to add new functionality to it, but now the micro front end offers options.
The micro front end gives us more freedom to make independent decisions about each part of our product, enabling incremental upgrades to our architecture, dependencies, and user experience. If there is a major incompatibility update in the main framework, each microfront can choose to update at the appropriate time, rather than being forced to halt current development and update immediately. If we want to try new technologies, or new modes of interaction, it will have less impact on the whole.
Simple, decoupled code base
The source code base for each individual microfront-end project is much smaller than that for a single front-end project. These smaller code bases will be easier to develop. More importantly, we avoided unintended inappropriate coupling between unrelated components. Reduce this unintended coupling by reinforcing the boundaries of your application.
Of course, a stand-alone, high-level architectural approach, such as a microfront end, is not meant to replace good old code with clean specifications. We don’t want to avoid code optimization and code quality improvement. Instead, we trap ourselves for success by making it harder to make bad decisions and more likely to make good ones. For example, we made it difficult to share domain models across borders, so developers were less likely to do so. Similarly, the micro front end forces you to explicitly and deliberately understand how data and events are passed between different parts of your application, something we should have started doing a long time ago!
Independent deployment
As with microservices, the independent deployability of the microfront end is key. It reduces the scope of the deployment, thereby reducing the associated risk. Regardless of where your front-end code is hosted, each microfront should have its own continuous delivery channel that can be built, tested, and deployed all the way into production. We should be able to deploy each microservice without considering other code bases or channels. Even if the original single project was manually released quarterly on a fixed basis, or if other teams submitted unfinished or problematic code to their main branch, the current project would not be affected. If a micro front end project is ready to go into production, it should have this capability, and it is up to the team that builds and maintains it.
Figure 2: Each microfront is independently deployed to the production environment
Autonomous team
The further benefit of separating our codebase from the release cycle is that we have a completely separate team that can participate in the idea, production, and subsequent process of our own product. Each team has all the resources they need to deliver value to their customers, which allows them to act quickly and effectively. To achieve this, our team needs to be divided vertically by business function, not by technology category. One simple approach is to segment the product based on what the end user will see, so each micro-front end encapsulates a single page of the application and is held accountable by a single team. This allows teams to work more cohesiveness than if they were organized by type of technology or “horizontal” concerns such as styles, forms, or validation.
Figure 3: A team is responsible for each application
conclusion
In short, microfronts are all about breaking big things into smaller, more manageable pieces, and then figuring out the dependencies between them. Our technology choices, code base, team, and release process should all be able to run and develop independently of each other without too much coordination.
We will publish the article in installments. Subsequent articles will cover alternative integration approaches for implementing these capabilities, how to deal with implementation issues such as style and inter-application communication, and discuss some of the drawbacks, as well as detailed example implementations.
To know when we’re going to publish the next part, please subscribe to our RSS feed, Cam’s Twitter, or Martin’s Twitter.
Important changes
June 10, 2019: First issue published, exploring the benefits of a microfront end
If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.
The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.