The first thing we need to realize is that the architecture of every system should not be static, and rewriting should not be the only option to respond to business changes. However, often the migration business side of the architecture does not allow enough time for developers to smoothly evolve the old architecture into the new architecture in a short period of time becomes a problem to be solved.

Starting with a recent project I worked on, this article explains how we went from a single front-end application to a micro front-end application in two weeks.

Why this evolution

Either to solve a problem or to make a fool of yourself with a stupid solution. Microfronts and microservices are both solutions to problems, so see if your project is experiencing any of these problems before you decide to do it.

First of all, our project is a to-B delivery project, which is a system envisioned by an organization for its multiple departments To coordinate and cooperate for the vision. The staff of each department need to access one or more subsystems of the system in order to complete their own business.

In such a business scenario, at the beginning of the project, the back end naturally chose microservice as the solution to decouple business and reduce system complexity. However, the front end did not adopt the solution due to the lack of consideration and the conservative customer, but tried to distinguish each subsystem in the way of file directory.

After the first subsystem was delivered, we realized a few things:

  • After the first-phase project was launched, it was transferred to another group within the company for maintenance. When we were doing the following projects, it was inevitable that we would modify the first-phase or common code, and the two teams would inevitably cause code conflicts
  • The whole system is too large for us to absorb the entire contract. It is foreseeable that a third party or even a fourth party company will join in the delivery in the future. The current single application will not only cause a large number of code conflicts in the team, but also limit the technology stack of the whole project, which is not conducive to cross-team cooperation in the later stage
  • Although our application is deployed through AWS EKS without any downtime, the current architecture cannot be independently deployed. Each subsystem deployment requires the entire application to be packaged, and if an application fails, the entire system will be affected. The micro front end can do a better job in this regard

The timing of the evolution

Architecture changes are often the result of developers finding that the current architecture cannot cope with business growth and change and needs to be changed to accommodate the new business.

Another possibility is that the current services are complex enough that some architecture changes are needed to decouple services to reduce the complexity of the entire system and make the system easier to maintain.

Whatever the reason, actually starting to change the architecture requires extra time and effort in the delivery process. But as we mentioned earlier, often the business side doesn’t give developers enough time to evolve the architecture.

Choosing the right time also becomes an important point.

In our case, the timing was after phase 1 went live and phase 2 was in preparation, so we started the front-end architecture evolution in iteration 0 of the new project.

If we don’t have even two weeks, then we really have to add some Tech cards to the delivery process and deliver improvements on top of other branches.

The target

First of all, since it is an evolution of the architecture, there will be no completion, but there should be a minimum goal. As long as the minimum goal is achieved and the major problems in the development process are solved, the evolution is considered to have achieved the goal. Based on this, we planned corresponding goals before the evolution began:

  1. Do not move the infrastructure, save as much work as possible, package all applications and deploy them to the same Nginx, put different applications under different folders, and push customers to split the infrastructure after the subsequent project is stable
  2. Prepare for the worst. What if we don’t finish the split in two weeks
    1. Keep the master code still. Plan how to continue development on the master code branch and create a new branch to complete the code split
    2. Leave the existing pipeline standing to support the existing Master branch and create a new pipeline for the new application
  3. First, only split the whole application code part, always keep in touch with BA and back-end partners, with business form and permission design to guide how to split the front-end

Technology selection

This part may not be present in every evolution. In our case, we need to split a single application into micro-front-end. In order to reduce the workload of splitting and increase the maintainability of the project, we need to select an appropriate micro-front-end framework to solve this problem.

Coincidentally, shortly after this decision was made, the company released technical Radar # 23, and we noted that single-SPA had entered the “experimental” quadrant as a micro-front-end framework. Also in our sights is the Single-SPa-based Qiankun.

After finishing a small demo using single-SPA, I decided to use single-SPA without even knowing about qiankun. The reasons are as follows:

  • The ecosystem is complete, with detailed documentation on the official website and a series of community and official code base examples, as well as popular science videos uploaded to YouTube and B
  • Has solved all the problems we want to solve, and there are no fatal flaws from every source of search
  • When I was writing the demo, I met a demand that couldn’t be realized. That night, I asked a question on official Slack and received a solution reply the next morning

Task disassemble

When we meet the right time, we have made clear the goals we need to achieve, and what we need to do after completing the selection is to start. However, we have to remind ourselves again that what we need to do is smooth evolution, so the most important step is to prioritize various tasks. Usually, we will divide tasks into the following categories:

  • Tasks that have to be completed in a short period of time – tasks that, if not completed within this period of time, may block future business development and may put future deliveries at risk
  • Tasks that can be done later – tasks that do not block the development of the business, but that should be done from a business and technical point of view and will cost more resources to do later
  • Optional tasks – These tasks are often designed to enhance the development experience and do not directly affect the overall application or business
  • Unnecessary Tasks – These tasks can be done, but for various reasons are not on the current schedule and can be deferred until a better time

conclusion

In the daily development process, we need to take a high perspective, determine whether the current architecture can support future business forms and changes, and plan for architectural adjustments and evolution in time.

The bottom line is that most architectural evolutions begin when time doesn’t allow, and we need to have a plan for the entire evolution, prioritize all the tasks, do the most important parts first, postpone the less important decisions, and then scrap some things.

The other important thing is never to overdo yourself in this process. As developers, we all want to make the best of every technical improvement, but the result of overdo yourself is to try to do everything and end up doing nothing.

The prerequisite for successful delivery is smooth evolution.