Last year, when I saw some discussion about micro front in the community, I wanted to write an article to sort out my own views, but later I put it on hold for various reasons (mainly laziness). Today in the wechat group to see a lot of people talking about micro front, although regretfully missed the discussion, but also aroused their own desire to express. So here are some words to record their own views.

Let’s start with two ideas.

1. The micro front end is the mapping of Conway’s Law on the front-end architecture

The architecture of design systems is constrained by the communication structures of the organizations that produce these designs. – M.C onway

Conway’s Law is almost the theoretical basis for the micro front end (specifically, the microservice architecture). It points out that the larger the organization, the higher the cost of communication between its systems. An effective way to solve this problem is to break up large systems into smaller, autonomous subsystems. Once the system is internally dependent, more functionally cohesive, and less externally dependent, communication costs across the system can be significantly reduced.

In simple terms, the guiding principle of Conway’s Law is: If communication is a big problem, don’t communicate at all.

So in essence, the micro front end (microservice architecture) is about solving engineering problems that arise from collaboration between organizations and teams, rather than a purely technical problem.

The group was only half right. In fact, I was in charge of all the front-end applications. However, the main problem is that these systems are long tail applications with four years and 20W lines of code, and the products are still in continuous integration iterations. I have neither the energy to upgrade their technical stack, nor the motivation (interest) to communicate with each former application owner to understand some technical details.

This leads indirectly to my second point.

2. The micro front assumes that all large systems cannot escape the law of entropy increase

The assumption is that all large systems will go from order to disorder, and that the codebase behind them will end up as a mountain of shit.

If not, it must be because the technology stack used by the system is not updated fast enough, there are not enough engineers involved in the development of the system, and the iterations of the product are not long enough.

Subliminally, adopters of micro fronts do not believe that a system will iterate in a healthy way forever. Because the increase of entropy is always natural and easy, and against the increase of entropy, there must be enough external force intervention, enough cost input.

That’s why a lot of the users in Qiankun are trying to iterate on a long tail of new features, and when they can’t get anything done, they try a micro front end solution.

For this reason, the micro front is often an engineering compromise of “pessimistic engineers”, a defensive, and sometimes even an architectural strategy of “burying the hatches”.

Of course, in an ideal world, all technical problems should be fixed and managed correctly for an aspiring engineer, rather than just a workaround. But at the same time, all software engineering principles tell us that it is not advisable to spare no effort to optimize and solve a technical problem regardless of cost, especially if the input-output ratio of the problem is not high.

What microfront advocates is not a passive, capitulationist attempt to sidestep the historical legacy of the system, but to show us that many times we can make “God’s to God and Caesar’s to Caesar” by dividing and ruling.

If you do the following, you probably won’t need a micro front end

Based on these two points, we can conclude that you probably don’t need a micro front when there are the following scenarios:

  1. You/your team have a say in all of the architectural components in the system. Simply put, all of the components in the system are developed by a small team.
  2. You/your team have enough incentive to manage and transform all the components of the system. The benefits of directly transforming the existing system outweigh the problems caused by the mix of old and new systems.
  3. In terms of system and organizational structure, the components themselves are strongly coupled, self-consistent and inseparable, and the system itself is an “architectural quantum” of the smallest unit. The cost of separation is higher than the cost of governance.
  4. Extremely high product experience requirements, zero tolerance for any inconsistencies in the interaction of the product, which basically negates the technical strategy of incremental upgrades from the product

Here are a few things you might actually need a micro front end for

  1. The system itself needs to be integrated and there are generally two cases:

    1. The old system is not working, and new demands are coming. No commercial company would allow engineers to take an existing system offline for simple technical upgrades. And you probably won’t be able to access new features simply with an iframe, because the product says “bounce a box to the middle.”
    2. Your system needs to have a mechanism that supports dynamic pluggings. This mechanic can be a well-designed system of plugins, but once an application is plugged in or plugged into an app that is old enough to be expensive to retrofit, it can still be transitioned to a variety of micro-fronts later on.

  3. The components in the system have a clear enough service boundary to divide the service boundary by micro-front-end means, and to isolate the complexity in different system units, so as to avoid the infection of code corruption caused by the inconsistent speed of entropy increase and the problems of engineering collaboration caused by the different pace of RESEARCH and development.

It’s the same old idea that there is no silver bullet, and that architecture itself is all trade — off.

Most of the time, if something is “popular,” you can’t stop someone from using it.