Taking The Legend of Zelda: Breath of the Wild as an example, there are a lot of main quests to go through, with Link's ultimate goal being to take down Calamity Ganon and save Princess Zelda. And aside from the main quest, there's a lot of other gameplay content, like temple challenges, like side quests, like map exploration, and so on.
We can also use the learning of Vue3 as an example, the first thing we need to understand is the life cycle of Vue3, the whole Vue3 runtime went through what steps and core links, and then we go to learn some of its key APIs.
In other words, it is the "dots" and "threads" that ultimately make up the complete picture of an event. It is through the linking of dots and lines that our body of knowledge, the "surface", is formed.
1. Micro front-end split idea
When I first ventured into the world of micro front-ends, a series of terminology immediately caught my attention: iframe solutions, routed micro front-ends, micro-pieceization, micro-application, NPM solutions, Dynamic Script solutions, Module Federation, and so on. These terms are like keywords in the micro front-end world, each representing a specific technical means of implementing a micro front-end.
When faced with these technical points, my initial confusion was: although these technical points are specific, can they constitute a complete technical program? Can they be used as a guide at the theoretical level? With these questions, I started to explore the nature of micro front-end. In my understanding, these technical points are more like surface applications for realizing micro front-end rather than deep-level theoretical guidance.
It wasn't until later that I learned the concept of splitting horizontally versus vertically.
1.) Horizontal split
Let's take a look at the image below.
We can see from the picture that the whole page consists of three parts, namely the header and footer, the rotating image and the official website detail display, which is a very common official page. But it was developed by three teams collaboratively and assembled the output on a single page. This approach provides a lot of flexibility and gives us the possibility to reuse the micro front-end in different views.
In my personal understanding, horizontal split is more inclined to modularization, especially applied in consumer-oriented (ToC) projects. Imagine video broadcasting sites like Tencent Video and Aqiyi, their core functions, such as video playback and video display, are usually well-functioning, content-rich, and multi-page reuse. These features make them ideal for optimizing the micro front-end architecture through horizontal splitting.
To put it another way, the concept of actually splitting horizontally, which I touched on early in the first chapter, is modularity. We can think of one or more of the core functions as a module so that they can be flexibly applied to various parts of the overall site as needed.
Horizontal splits pay particular attention to the reusability of business functionality and the overall search engine optimization (SEO) of the site, as SEO is a given for consumer-facing (ToC) projects.
Due to the need to combine multiple modules and to technically optimize the SEO of the website, as well as to clearly delineate the boundaries of responsibility of different teams, horizontal splitting undoubtedly faces more severe challenges in terms of technical implementation and team collaboration.
2) Vertical split
Let's just take a look at the chart.
The figure shows two pages, each of which has a different business responsibility. We can see that one is the product details page and the other is the product creation page. Despite their different business functions, they share the header navigation and side navigation sections. This way of having one team responsible for the design and development of the entire page is known as vertical split. In this scenario, how to split the business wisely can be done with the help of Domain-Driven Design (DDD) as a guideline.
If you write single-page apps often, vertical splits are actually easier to understand and implement than horizontal splits.
I don't know if you remember the phrase called front-end is naturally decoupled to a certain extent. What does it mean? That is, often, we are in the development of the distribution of tasks, rarely say, you write a search box, he wrote a list, and then finally combined together, but you write this page, he wrote that page, and ultimately in the merger of the project will not interfere with each other and dependence. And this scenario, as well as the split, is actually more suitable for ToB background management system, SaaS type projects.
Such projects often have clear business domains and scopes, but the business logic and scenarios are varied and complex. Vertical splitting can aggregate development and product teams that have a deep understanding of a certain area, focusing on a single area and bringing greater advantages to the iteration and development of the whole project.
2. Limiting context
About bounded context, and how to distinguish between core subdomains, supportive subdomains, generic subdomains such concepts I do not want to discuss too much here, this book after all, is not to talk about domain-driven design, if you are interested, you can learn on your own, I would like to chat with you is that the concept of bounded context, in the field of micro-front-end in a position, what is the role of.
Limit Context As I understand it, it's really about what kind of logic to split the micro front-end according to, for example, we can split it according to the business scope. In a usual SaaS system, it can be split into subsystems for accounts payable, order creation, products, warehousing and so on. In a ToC online shopping software or video website, it can be split according to its reusability or functionality, such as shopping cart, product list, product details, or video player, video details and so on.
But very often, some theory may not be so useful, for example, there is an old SaaS project, the entire directory structure and business areas do not match, all flat out, but now the leadership hopes that new technologies can be applied to the old project is also integrated into the development of new business, to achieve the project on the unification of the big. Do you remember before we talked about the use of micro front-end scenarios, incremental upgrades that, and now we are going to do such a thing.
What should we do? If I split the old system, differentiate between the business domains to which it belongs, it will take us a lot of time to separate the subsystems, the old project is very stable, there is no need to change, but if you do this, I do not know how many problems to bring to the test, development, so we hope that the old system does not move, and directly use the Nginx reverse proxy or iframe will be fine. Yes, that's a good choice, but it also begs the question, are you following domain-driven design? Obviously not, but it's a necessary and right wrong choice.
What the above example is trying to tell you is that theory is a necessary tool to guide practice, but very often, we may not always have to follow the theory.
3. Combinations
The concept of combination actually refers to how we are going to put together and load the micro-front-end interface, for example, we are familiar with qiankun, wujie and other micro-front-end frameworks, all belong to the client-side combination of the category. In addition to client-side combinations, there are also server-side combinations and edge-side combinations.
Let's first understand such a process, when we see the interface in the browser, what happened before that. It is very simple, it is from the server to get the resources needed for the interface, such as html, js, css and these, and then after the browser's analysis of the rendering, and ultimately render the interface. But in order to get the resources faster, in the middle of the client and the server, there may often be a CDN used to store the static resources of the front-end, so as to speed up the speed of access.
So let's understand three more ways about combinations:
- Client-side combination: actually loads the micro front-end and its related functionality via js at client-side runtime, and everything is done on the client-side.
- Edge-side combination: we will combine views at the CDN layer, which can be accomplished through an XML-like markup language called ESI.
- Server combination: In fact, to put it bluntly, is similar to SSR, in the server's runtime or compilation time for the combination, patchwork micro front-end so as to generate the final view of the results, return to the front end of the complete HTML, so that the biggest advantage is to enhance the client's experience as well as to provide good SEO results.
4. Routing
In the modern single-page application is so widely popular, we must not be unfamiliar with client-side routing at all. In most cases, we choose what kind of micro-front-end combination, will correspond to the use of what kind of micro-front-end routing. Of course, this situation is not absolute, for example, assuming that we choose a combination of servers, but the server to withstand the pressure is too large, you can route the distribution of things to the CDN to do, that is, edge-side routing.
I want to emphasize a little bit here that CDN routing or CDN combinations are one type of solution that belongs to the edge side, but the edge side isn't just one type of CDN. Edge computing is a distributed computing paradigm that places computing resources and data storage close to the end user in order to provide lower latency and higher performance. In other words, the enhanced capabilities caused by some intermediate or additional infrastructure to augment the client or reduce the stress on the server can be counted as edge-side.
Either way, in practice, we are not limited to a single choice. That is, we can either combine components on the client side or partially combine them on the server side. At the same time, we can either implement client-side routing or, for some specific paths, request data directly from the server side or get it through a content delivery network (CDN). This flexibility allows us to choose the most appropriate implementation based on the specific needs and characteristics of the project.
5. Communications
In terms of the definition of a micro-front-end, we don't actually need communication between subsystems, because a micro-front-end is by definition independent and autonomous, and it shouldn't have any theoretical communication or relationship with other subsystems. But I have also emphasized many times that theories are often not that useful, and we don't need to be dogmatic about them.
Although micro front ends are defined so independently, communication between them is necessary in most scenarios. For example, sharing login status, transferring information between subsystems, and so on.
If you are in the same domain, you can use WebStorage's SessionStorage, LocalStorage or cookie to share the login status. Even if you are cross-domain we can use postMessage to communicate.
But let's say, you cross-domain a project that is not self-developed, i.e., you want to access someone else's cross-domained project, and you can't get the source code or private deployments yet, well, do you still need to communicate?
A little brainstorming for everyone, let's continue ha. In addition to the above scenarios, we can also utilize off-the-shelf frameworks such as wujie, qiankun, etc. for off-the-shelf out-of-the-box means of communication.
Of course, in addition to these we can also implement a simple EventBus for data sharing ourselves. There is another option that we commonly use, which is to communicate through the URL query, this option is simple and practical, almost no technical difficulties, but if you want to make a generalized method of passing parameters to URLs to practice in the micro front-end, you also still need to think a little more.
Finally, let's summarize what are all the viable options for communication in a micro front-end.
- WebStorage
- Cookie
- PostMessage
- EventBus
- Custom events, i.e. publish-subscribe model
- URL
- Other: e.g., etc.
- Vuex, Redux, and other state management tools.
6. Segregation
The topic of isolation wasn't born with the advent of the micro front-end concept; it's always been around and has always bothered developers. We all want a clean, unobtrusive environment to utilize our technical talents. However, issues such as JavaScript variables that may be overwritten by later code and the use of CSS selectors that may inadvertently lower the priority of other styles can be a real headache.
So js has evolved from IIFE to the canonical ES Module, and css has its own scope in certain specific areas. so what is the best way to deal with the isolation of js and css in the context of a micro front-end?
In the native context, we are all based on iframe or webComponent as the micro front-end practice selection, so as to carry out the isolation of js and css from the fundamental point of view, and then go to solve because of the selection of some of the side effects brought about by this program is the isolation of wujie micro front-end framework solutions.
Of course, in addition to the native solution, we can also use namespaces such as BEM and other namespaces CSS naming to isolate CSS, through the shadowDOM to natively isolate CSS and HTML.
About JS isolation, the program in fact, there are many, such as Webpack Module Federation, a variety of micro-front-end frameworks, etc., but the core of their realization, still can not be separated from the basic principles. Take JS, you get to the runtime environment, to isolate the words, is nothing more than modular or IIFE and other basic JS isolation program.