In 2017, I took over a user background management system. This project has always been maintained by Java backend students. Maybe because different groups would make modifications, many pages were almost impossible to maintain, and even multiple jQuery libraries covered each other in one page. Also, because each group changes, and the original requirements document is missing, which features are available and which are no longer needed are in an unknown state. In addition, the UI design of the page looks too old and old, as if back to the 56K Internet era.

Era 1.0: JSP+SPA

It is imperative to demolish and redo the whole station, and the product also has this intention, so hit it off immediately, happy (there is no) to determine the plan, but due to the pressing time, made more technical compromise.

  • Since the original system was ie6-compatible, the product didn’t want to change it too radically and was only allowed to upgrade to IE8-compatible
  • Because there are common parts of the page, front-end routing is required to reduce the loading of the same content and improve the speed of page hopping
  • Page from the original JSP straight out, changed to JSP+SPA

Front-end stack: JQuery + Requirejs + ArtTemplate

Back end: JSP straight out

Page content layout is similar to the holy Cup layout (as shown below)

  • Public header (site-wide)
  • Left navigation (for this system)
  • Business content section
  • Common footer (site-wide)

The page directly out of the JSP also contains the above sections, because the header, navigation, and footer are common to each page, limiting the front-end routing to the business content section. When a route jump is triggered by clicking the navigation on the left or the business content section on the right, the front-end route is followed and only THE HTML of the business content is requested (no need to load the header and footer).

The page routing logic is as follows:

reflection

  • Although we solved the problem of reloading common content on pages by introducing front-end routing, we could not use the industry’s MVVM frameworks Vue or React due to the need for COMPATIBILITY with IE8, resulting in the need to duplicate wheels.
  • The development process found more pages, its content and layout are relatively close, can abstract a set of business UI components used, but the existing based onJQuery + Requirejs + ArtTemplateTechnology stack, the implementation of the availability and maintainability is poor.
  • Without a business UI library, every function and requirement requires design resources, and the front end needs to be re-mapped every time, which is especially labor-intensive.

Age 2.0: SPA & UI library

Vue 2

Time came to 18 years, after one year of iteration, the reflection problems mentioned above increasingly restricted the development of the project, coupled with the user data of this year, the number of users using IE8, 9 and 10 has become less and less, so I resolutely persuaded the product to no longer support these browsers, and FINALLY Vuejs can be used.

Vue 2 based UI library

Next, the front end and design, product together with repeated discussions, together to determine a uniform SET of UI design specifications, and based on this set of specifications, combined with business scenarios, abstract a set of business UI library.

The reasons for not using existing UI libraries on the market (e.g. element-UI, iView, etc.) are based on the following considerations:

  1. We have our own design specifications, it is not appropriate to copy the existing UI library, but also need customization. The learning cost of studying the existing UI library is not much less than that of making a new set, and the later expansion may need further magic changes, which may be subject to some restrictions. This includes version updates, potential bugs (remember AntD’s Hohoho), and more.
  2. We need not only basic UI modules such as Button, Spinner, etc., but also business scene UI modules such as Searchbar, Dialog, Avatar, etc.
  3. I hope to improve students’ technical ability and level through the development of business UI library. After all, use and development are two different things, not to mention that they are both developers and users, so they can have a deeper understanding of this.

In the end, it took 60 people days to develop the first version of the business UI library with 24 UI components. It also took 60 people days to refactor the original page using the Vue 2 + business UI library.

Although this upgrade and reconstruction cost a lot of manpower, it actually saved a lot of manpower in the long run for a project with continuous new requirements and version iterations.

  • With the UI components already in place, many requirements no longer require design resources, making the project lifecycle more compact.
  • New scenarios require new UI components, and once they are first developed, they can be added to the UI library for continuous refinement and expansion.
  • With UI components on the front end, ready-made components can be directly nested, and according to observation, development efficiency can be improved by at least 50%.
  • Design specifications and user experience have been unified, reducing user learning costs.

3.0: TypeScript

Soon after another year (19 years), with the passage of time, the functions of the project gradually accumulated and increased, the business process became more and more complex, coupled with the flow of developers, the logic of many functions could not be clearly explained in a few words. New colleagues or temporary help will encounter a headache problem, how to modify this code, these variables and objects, need to go deep into the query context, in order to have a clear understanding of the overall appearance, but this process takes a lot of time. So we found TypeScript to make our code more readable and maintainable.

TypeScript

Personal benefits of TypeScript include:

  • Static type marking, with workflow/IDE for type detection
  • The IDE does syntax hints
  • Easy to refactor and extend

Of course, there’s no such thing as a free lunch, and these benefits come at other costs:

  • The cost of learning TypeScript
  • The first development time of new features increases, with the extra time spent declaring various interfaces, types, and so on
  • The mental cost of developing TypeScript, after all, is that it’s not really a statically typed language, and sometimes you have to carefully distinguish between what code is markup and what is actually compiled into JavaScript
  • Some of the more flexible uses of JavaScript themselves are unavailable or require more declarative markup (see TypeScript minicondition traversal object properties here)
  • Some external libraries that don’t have TypeScript support themselves either import AnyScript (which is against the intent) or write d.ts to the library (this will be much better now in 2021, but it would have split people in minutes back then).

But it soon became clear that things were not quite so simple.

When we tried TypeScript on Vue 2, it didn’t go so well because Vue 2 wasn’t developed with TypeScript in mind, so developers had to go around in a very roundabout way, which dramatically reduced productivity to an unacceptable level. We tried two features. Increase your workload by 25-50% on average.

React

At this point, we looked at React.

React works better with TypeScript than Vue 2 and is much smoother to develop with. It also raises the question of how to use React when the same project uses Vue 2.

At that time, considering the time constraints, we used a more direct approach ————iframe. Vue 2 was used for the whole project and for most of the functionality, while React was used in the new standalone project and a PostMessage-based bridge was developed for the main page to communicate with iframes (iframe routing changes, page loads, scrolling, etc.).

React based UI library

At the same time, we need to develop a React version of TypeScript using the Vue 2-based UI library. Thanks to previous experience in UI library development, the process of developing React version went more smoothly this time. Although many students in the team were not familiar with React at the beginning, they quickly got used to it while developing business and completing UI library components.

4.0: The micro front end

Unconsciously, our background management system has reached the fourth year after taking over in 2020, and this system has become a large project with 25 functional modules and 72 sub-functional modules.

Pain points

As the project continued, we gradually encountered some pain points:

  • The project contains a variety of complex functions, and modifying a function requires the whole package construction, as well as testing regression, pulling the whole body.
  • When multiple people are developing at the same time, code consolidation is often required.
  • As code gets bigger and bigger, it takes longer to build and publish, affecting development efficiency.
  • After long-term maintenance and iteration of the project, the advantage of the technology stack selected at that time is no longer, but has become a historical burden. Therefore, the new function cannot choose the technology more suitable for the business scene, and can only use the original; The entire project using a new technology stack would require a costly refactoring.
  • For some common functions, the external system can only copy and paste one copy of the code, and maintain two copies of the code later.

The solution

By accident, we came across a microfront-end framework that, upon closer examination, solved our pain points.

The value of

  • Technology stack independent (parent and child applications can use different technology stacks)
  • Application independence (Each application can have independent runtime, independent code repository, and independent build/release process, so that development and deployment do not interfere with each other, and the application can be better reuse)
  • Progressive upgrade (Each application can be upgraded separately, making the upgrade process smoother and more controllable)

The project structure

Implementation of the plan

  • Complete the infrastructure advance work
    • Micro front-end framework of encapsulation and fitting business (including routing support and application communication module)
    • The UI library supports custom prefixes (different versions of the UI library may be used by different applications)
    • Workflow transformation supports micro front end projects
  • The project parent application connects to the micro front end
  • Child applications are connected to the micro front end
    • The new function is developed directly for micro front terminal applications
    • Old functions are transformed decisively when new requirements are involved
    • Retrofit old functions as resources/time permit

Due to urgent business needs, there was not a whole period of time to carry out the transformation, so we adopted the form of stages, and finally completed the micro front-end transformation in five stages and lasted two quarters.

Real income

  • Whether it’s a project build or a code merge for multiple developers, it makes development more efficient.
  • Interactions and dependencies between projects due to omissions are reduced, quality is improved, and time spent testing regression is reduced.
  • React functions and Vue parent applications that need iframe solution can be directly connected to the micro front-end to optimize page loading performance.
  • The obstacle of upgrading the new version of the technology stack or other technology stack is removed, and each function module can be completely selected according to the business needs or technology trend, instead of being tied to a tree, the technology iteration and upgrade is smoother
  • Child applications can be accessed individually or introduced by different parents at the same time.

Coincidentally, we will soon put this background management system, according to the role of the user divided into two projects, some of the common basic functions, in the transformation into micro terminal applications, can be successfully used by two projects.

The future planning

Considering the background management system itself logic and page UI similarity, the future will go to the direction of low code, save the workload of business development, do other more valuable and meaningful things.