With the complexity of the middle and background systems, it is often encountered that sub-applications independently maintained by multiple teams are connected to the unified main application. These sub-applications are often developed independently, deployed independently and completely decoued from each other. At this time, the usual single application cannot meet the growing needs of the business. The micro front end is designed to solve the problem of a single application evolving into a “monolithic application” that is difficult to maintain as business complexity increases over time.
This article is not a source code analysis and start tutorial article, I want to introduce the micro front end from a macro point of view and briefly talk about the micro front end in our current project some thinking.
Let’s talk about the background
I’ve always thought that technical changes that take away from the business are of little value and hard to get far. Here I would like to briefly describe an architectural evolution and some simple reflections that I have made on my current project. I am currently working in a large B-side project team. The system has dozens of sub-applications according to business domains, and the system PV is hundreds of thousands of +. Therefore, in such a huge system, our system architecture has also experienced the following changes.
Template architecture
When I first joined the team, our system was still an architecture with the front and back ends not completely separated. Templates provided a portal to mount the root node, and the front end rendered React/Vue applications on the root node.
It is not hard to find that such an architecture has certain drawbacks:
- Back-end parse templates, mount templates;
- The back-end controls routing, while the front-end loses control of routing, and it is difficult for multiple teams to control routing rules.
- Each front-end release needs to release static resources and then release templates, which is tedious and error-prone.
- This approach to development is relatively old, and it’s hard for the front end to get excited about doing new things;
But fortunately, at this time, our system has a certain didivide and conquer idea, the main application (should be said to be layout layer at this time) and the sub-application separately mounted on different template fragments, which also reduces a lot of work for the later IFrame and micro front end transformation
In fact, this architecture also has some shadow of a micro front end :).
The iframe architecture
Later, with the transformation of back-end microservices, the back-end no longer cares about the control of routing and page mounting, but instead provides more atomized microservices. And for our front end:
- Need to be independent of back-end templates;
- Routes need to be controlled and unified routing rules should be formulated.
- Sandbox isolation for master applications;
- Try to minimize the changes to the sub-business, many business burden is very heavy;
- Fast landing and high availability (no way, development time is always a factor that beats many options…) ;
However, with the implementation of iframe architecture and subsequent iterations, we also found some disadvantages of iframe scheme:
- The communication mode is simple, and the simple PostMessage API does not meet the needs of the business;
- Split styles. Iframe causes global masks such as Dialog to be displayed only within the ifame block, making our system more like a “patchwork”;
- Performance bottleneck, route switching will lead to iframe child application reload, performance is worrying;
- Cross-domain problems. Chrome80’s Samesite policy causes cross-domain cookies of iframe scheme to fail to be brought to the back end.
Microfront-end architecture
Finally, in the middle of this year, I upgraded the IFrame architecture to the micro-front-end + IFrame architecture, and developed and implemented a series of micro-front-end related development tool chains (Xida Proben…). .
So, why not iframe?
In my opinion, the micro front end is an idea and the evolution of a development mode and architecture. Frameworks such as Qiankun and ICestark are only the implementation of the micro front end, and the reasonable iframe implementation is also the implementation of the micro front end. Our original IFrame architecture was partly a micro front end idea, and in my opinion, IFrame still has natural advantages for this kind of cross-team big backend project for the following reasons:
- Framework-free: Iframe only loads the deployed app link;
- Separate sandbox: Iframe has a separate sandbox with a browser, and the child and main apps are completely free of JS & CSS contamination;
- Simple to develop: just one iframe tag;
But along with that comes some of iframe’s pain points:
- Poor UI experience: Iframe is only rendered in the specified render block, while some global UI components of sub-applications, such as Modal with mask layer, are only rendered in iframe;
- Communication difficulties: The side effect of iframe’s powerful sandbox mechanism is that parent-child application communication is difficult. It is difficult to implement a postMessage API, cross-domain cookies, promises, etc.
- Route loss: The URL change of the child application cannot be synchronized with that of the parent application. As the page is refreshed, the route status of the child application is lost.
- Long loading time: each sub-application is a process of browser context reconstruction and resource reloading;
Although the above pain points are more or less combined with some hack tools and development specifications have a certain solution, but there are better options why not try 🙂
So, what is a microfront end?
I’m not going to talk about concepts here, we all know the truth, concept search is all. For example, the micro front end is very official:
Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently
Just like the boulder application is not overnight, I will introduce you to my understanding of the micro front end through the evolution of a boulder application.
A single page
Initially our system might have only one business module. Routing is hardcoded in the project, and the Layout layer and business subsystem are written together.
Multiple pages
With the growth of business, our system was connected to more business modules. At this time, the project was not a big problem through certain routing configuration and multi-page configuration.
However, we need to be alert at this time. If more business modules are added and still remain in the current mode, how should the project be maintained?
More pages? Stonehenge app!
With the further growth of the business, more and more business modules will be connected. Not only will we expand the sub-applications in the navigation dimension, but even there will be blocks belonging to multiple business domains on pages such as the home page. There are two types of scenarios:
- Single instance: one or more pages correspond to one child application, and only one child application is displayed at a time.
- Multiple instances: A page contains multiple sub-business application blocks, and multiple instances are rendered and displayed at the same time;
If there is no good processing and subsystem separation, then our application will become a boulder application…
- Developing iterations and launching a monolith app is much more painful than launching multiple sub-apps…
- With multiple people (multiple teams) working on a project, you never know what others have done or will do…
- Often this kind of application, everyone is adding instead of subtracting, making the project bigger and bigger, useless code more and more…
Micro front end, divide and conquer!
At this time, we often divide the system into different sub-applications according to the division of business domain, and the layout layer bearing these sub-applications is divided into the main application. Each sub-application is independently developed and published, and maintained by different business teams, so as to solve various development and maintenance problems caused by complex single application.
It can be seen that the micro front end takes the idea of divide-and-conquer to avoid monomer applications evolving into monolith applications.
In my opinion, in the micro front end idea, the key points are:
- Independence: the main application and sub-applications of the micro front end are independently developed and deployed, and to some extent the micro front terminal application can run independently from the main application;
- Sandbox isolation: Child applications have their own separate runtimes, and state is not shared between child applications;
- Framed-independent: Sub-applications can be developed using different frameworks, because in the implementation of the existing micro-front-end framework, the main application is only the bundle loaded after the sub-application construction;
Our choice
At present, there are many micro front-end frameworks on the market, such as Icestark and Qiankun, two mature open source micro front-end frameworks in Ali, and singleSPA in the community. So how do we choose the micro front end framework suitable for our project? Here I briefly list some thoughts when I choose the micro front end framework:
- Cost of change: No business team can avoid this topic, how do you convince the product and boss that such a long technical change is necessary (there are risks involved), and how do you convince sub-applications to cooperate (trust me, sub-applications don’t want to do > 1-day changes…). ;
- Sandbox isolation: Without further ado, many child applications integrate their own buried and monitoring systems, which tend to mount or hijack global variables;
- Route immutability: In our IFrame architecture, there has been a set of relatively complete routing rules, so how to ensure the same route on the premise of the architecture upgrade?
- Communication invariance: Similarly, in our IFrame architecture, we have a set of mature communication tools, so can we complete the communication of the micro front end on the premise of ensuring the API remains unchanged? Or just micro front end can take iframe communication tool?
- Iframe compatibility: Such a large system does not migrate to the micro front end all at once, and we have no intention of abandoning the IFrame architecture. . So how do you ensure the coexistence of the two architectures? Further, how do you ensure that the two architectures coexist and still share a set of rules?
- Grayscale control: the release of large version of sub-application is often accompanied by grayscale control, so how to ensure that there can be a complete grayscale process after micro-front-end access? Do you make a version control tool or use htmlEntry directly?
- “Ancient” app access: Ancient apps are best with iframe embedded, so can we be greedy to support “ancient Dragon” silk access?
Finally, based on the above considerations and our current system architecture, I chose Qiankun to implement our micro front end solution. In order to ensure the convenience of micro-front-end access and version control, we implemented some micro-front-end ecological chain tools.
conclusion
The above is when I do micro front-end transformation combined with some thinking of the business system, if there is wrong place welcome to correct. After that, I will also output the source code analysis of Qiankun and the principle analysis of some micro front-end tools I have done. .
🏆 technology project stage 4 | chat micro front end of those things…