Abstract: From browsing pages to management pages, see how Huawei cloud official website builds a low-code platform in stages according to business scenarios to improve page iteration efficiency.
This article is shared from huawei cloud community “Huawei cloud official website front-end technology evolution and Low code practice [World Software Conference Technology Sharing]”, the author of the original text: technology torch bearer.
Front-end team evolution often goes through stages of componentization, configuration, and visualization, and low code is an inevitable result of team evolution.
At the 7th Global Software Conference, Guo Xiao, huawei front-end R&D engineer, shared the practical experience of huawei cloud official website on how to build low-code platform in stages according to business scenarios and improve page iteration efficiency. The following is the shorthand of the on-site speech.
Three big challenges for the front end team
The reason why the term low code is so popular recently, and there were more than 5 low code related shares at Qcon, is the root cause of some problems that front-end teams have encountered in recent years.
The first is the proliferation of pages. According to IDC’s presentation at the 2020 China ICT Market Trends Forum, the development of the digital economy will spawn over 500 million new applications/services in the next few years, which is about the same as the number of applications in the past 40 years. The rapid development of digital economy requires the transfer of massive information, and the front-end page as an important way to transfer information, the number is also surging.
A recent survey of 535 team leaders found that teams expected to hire a total of more than 9,000 front-end jobs this year, but only hired about 5,000, less than 60% of that number. And according to talent market data, The growth rate of front-end manpower has gradually declined since 2014, and the new blood in the front-end is decreasing year by year. Demand has increased, manpower has leveled off or decreased, and problems are already evident.
Finally, the operation and maintenance pressure brought by the surge of demand. Most of the front-end business demand comes from operations and products, and the strong correlation with business leads to the instability of demand. A live page may need to be re-launched with a minor tweak, which is time-consuming and costly. Moreover, after the number of pages is too much, some traditional content quality inspection through manpower will be very difficult, and the quality of online pages is difficult to be guaranteed.
So how does the team evolve against this backdrop?
The evolution of technology: from Slash-and-burn to visualization
At first, the front-end was in the primitive “slash-and-burn” stage, where pages could be stacked as long as there were three pedestals of HTML, CSS and JS. Gradually, we began to extract some common methods into the method library, general components into the component library, and combined with engineering ideas for some module reuse, that is, componentization stage. This was a time when code was still being written, but the reuse of code began to improve project efficiency.
After componentization, we found that in many business scenarios, components were often grouped together and business components began to appear in the component library. For example, a page will often have a floor with a main title and subtitle centered above it, and several cards below it, each with a background image and a description. So let’s build these big particle components for reuse.
As component granularity increases and business components increase, the amount of code required to create simple page requirements becomes less and less. It is often just a matter of importing a few components and passing a few parameters, because much of the logic is already encapsulated in the components. At this point, we write the components and parameters to the configuration file, and then write a set of parsing logic (the rendering engine) to parse the contents of the configuration file into object code. In this way, you only need to maintain a configuration file and enter the configuration stage.
In the configuration phase, the DSLS are written without stack awareness and business process awareness, and the final rendering is completely controlled by the rendering engine. At this point we can expose the maintenance rights of the configuration file to the application side developer: we maintain the rendering engine, the component library, and the application side developer maintains the configuration file. This reduces the coupling between the team and the business, further saving manpower.
Considering that the application side does not necessarily need to be developed, and also for the application experience, we can provide a page for users to drag and drop components and edit, and turn the user’s operation results in the interface into DSL, so that the end user can generate the final page without sensing DSL. The simplicity of the operation makes it possible for non-developers to master it, and gradually it becomes a matter of who needs what.
It can be seen that in the development process, we continuously extract common capabilities and abstract business processes, and finally achieve low-code, code-free capability openness, which greatly reduces the maintenance pressure of the front-end team.
There are many examples of similar evolutions in the industry, where low code is slowly coming into view.
How to select low code platform?
The concept of low code was first introduced overseas, and companies such as outSystem and Mendix have long dominated low code platforms. The country was late to the game, with the first commercial low-code platform only a few years ago, but now there are a lot of arguments, including Huawei’s AppCube.
The “low” of low code can be understood in two ways:
First, the cost of application production is reduced. Low code not only means that less code is written in the development process, but also means that the overall process cost such as application deployment cost is reduced.
Second, the technical threshold of application production is lowered. The shielding of underlying business logic and technology stack enables non-professional developers to quickly put into application production even after simple IT training.
So in a low code wave, how does a front-end team choose?
First look at whether the front-end team necessarily needs a low-code platform. It is estimated that more than 95% of scenarios in small and medium enterprises can be built on low-code platforms, and more than 70% of scenarios in medium and large enterprises can be built on low-code platforms. As we mentioned earlier, low code is a natural consequence of the technological evolution of front-end teams, so a low code platform is a must.
The question then arises, is it to buy directly to use or to research? We compared it from three dimensions of scalability, ease of use and labor cost.
In terms of scalability and ease-of-use, if you buy an industry platform, you can only use the platform capabilities exposed by it. Although the platform opens some customization capabilities, it cannot meet the needs of complex services on huawei cloud official website. In terms of cost, the platform of the whole process from development to launch includes low code construction of data model, UI, logic and process, and high labor cost of construction.
If the team size is small or the business scenario is relatively unified or the team is still in the componentized stage, I suggest using an industry platform, such as Huawei Cloud AppCube, to save time and effort.
However, if the team is large, the business scenario is complex, and the evolution of the team is already in the configuration or visualization stage, it is better to develop a set of own in the long run. Because when enterprises or organizations develop to a certain extent, they will gradually give up all kinds of outsourced components and build self-research capabilities to meet the needs of their own organizations.
For our team, considering the importance of scalability over labor costs, we chose to develop a low code platform.
Then how does huawei cloud official website carry out low code practice?
Huawei cloud official website low code practice
Huawei cloud official website contains the following three pages:
Browsing pages, such as product introduction pages and document pages, are characterized by floors, and most of the page components are cards, texts and pictures. Floors are independent of each other and have little interaction. The language is based on XTPL.
Management desk page, such as billing center, internal management page, because the chart page is the main, this kind of page interaction is relatively fixed, including search, add, delete, change, check, etc., the language is VUE.
Purchase page, such as activity page, price calculator, this kind of page mostly presents product specifications, page interaction is more complex, the language is also VUE.
Among them, browsing class and management desk class page probably accounted for more than 90%.
In low-code practice, the overall goal of Huawei cloud official website is to achieve an efficient application production platform for operators and developers, which is internally called HPA. Functions of the platform include but are not limited to low-code or no-code generation of data models, logic, UI and processes.
According to the business background, we will initially divided into two stages, the first is for the browsing page, to achieve the browsing page without code generation, at the same time, to build the platform ability, to achieve the page from production to release without code.
The second stage is to enhance the non-coding capability of the platform, and extend the low code generation of the page to data model, logic and process dimensions.
Stage 1: Browse pages are low code
The first low code is the browsing page, because this kind of page number is large, large labor consumption, and the page composition is relatively simple, low code cost is relatively low. Our approach to building low-code UI is componentization, configuration, and visualization.
componentization
The key to componentization is to deal with commonality and customization of pages. The commonality of browsing pages is the floor dimension, and the floors are independent. Customization is the fact that some pages have some non-floor components, such as floating Windows or a little global logic.
We first classified the pages according to different customizations, forming some page templates, such as general page templates and other product page templates, news page templates. A page template usually contains the header and footer, as well as the customization logic mentioned earlier, such as the official website service guarantee page, using a generic page template that only contains the footer.
Then, the common part is dealt with. We split the page into floors. The service guarantee page of the official website can be composed of five types of components, including components 2 and 3, which can be reused. We incorporate the customization of the page into different page templates, and the commonality is the reuse of floor after floor components.
Configuration change
After componentization, it is how to describe the page with configuration information. The configuration information contains the page template, page structure, page data, and dependency information.
Page templates describe header and footer and page customization information. The page structure describes which floor components are used and in what order. Users are modifying the page structure file by dragging and dropping components on the canvas. The page structure also records the relationship between the floor components and the page data.
The page data describes the specific configuration data of the floor components, and the user is adjusting the page data by editing the component content on the canvas.
The final HTML page can be rendered using a DSL rendering engine by adding version dependencies for floor components and tripartite components
visualization
Once the page is configured, it is time to consider how the end user generates configured information through the interface.
The following figure shows a diagram of page structure editing and page data editing. Page structure editing is a process of dragging components from the component market on the left side of the canvas to a specified location on the page. Components in the component market are developed through a native IDE and then uploaded via NPM distribution. Page data editing is to click the target component and edit in the component editing box that pops up. The component editing box is defined in the component using a syntax similar to JSON-Schema. After editing, you can choose to publish, preview and other functions.
Page access
When published, the canvas stores the page configuration data to a back-end database for subsequent unified data microservice calls.
During the live network access, if the CDN fails to return to the source, BFF will obtain the page configuration of the current page, including the page template, page data, and dependency information, according to the unified data microservice based on the page URL. Then go to OBS to obtain the corresponding floor component content according to the dependency information, and render the final page according to the DSL rendering engine mounted by BFF.
The difference between the preview state and the running state lies in whether there is CDN, and the data information is transmitted from the front end to BFF, without BFF to unify the data microservice access.
HPA platform 1.0
The above mainly introduces the browsing class page from componentization to visualization process and the effect of the final running state. But as a platform capability, backend and infrastructure support is also very important.
The module diagram of HPA platform made by us in the first stage mainly consists of four layers.
The infrastructure layer includes Huawei Cloud service, database RDS, cloud search CSS, object storage OBS, Redis, distributed message notification, and ModelArts, a one-stop AI development platform.
The micro service layer provides user authority management, and with workflow, message notification specifies which pages the user can edit and who needs to review after editing. Content quality check and gray scale test as the quality and style of the page before the launch of the report; Content management is the unified data microservice interface mentioned above.
The data center layer is where the BFF returns the rendered page based on the URL or call parameters.
The front-end canvas layer consists of component marketplace, asset management, application management, version management, and page editing. Application management here is very narrow, limited to the UI. The version management function mainly provides the page rollback, comparison and other functions.
Stage 1 Summary
HPA1.0 has achieved remarkable results. We currently maintain about 100 floor modules, as well as some custom floor modules, covering almost all of the browsing pages on the website. The reduced workload on the development side can also be seen from the usage of operations, with operators making an average of 6,000 self-service changes in the platform.
Moreover, the release process is also greatly simplified, and many changes do not need to be transferred to the development and then transferred to the test line through requirements, and can be operated independently, from day level to hour level. Finally, automated and comprehensive content checking improves page quality significantly.
While the obvious results have been achieved, it must be noted that there are still some points that can be optimized. For example, DSL is to render the browsing page, the scene is relatively simple, the subsequent processing of the management desk page will be very difficult, need to enhance; Secondly, these 100 floor components need to be developed and maintained in the local IDE, so the relative release cycle is still long. Finally, the lack of code-free process choreography ability, if the new permission group configuration process is complex.
Therefore, we continue to move to phase 2, which is to enhance platform capabilities for business purposes with low code on the management desk page.
Stage 2: Admin console class page low code
componentization
Management console page is a page type supported by low code platform in China. The following figure is a simple example of management console page. Part of the information in the figure is hidden.
The main body is a table with paging components below, new and search above, and search, change, delete buttons in the table. Pages are characterized by relatively fixed types of components, including tables, search, paging, pop-ups, buttons, and graph components. And the basic logic is relatively fixed, can be generalized to add, delete, change and search for the underlying data model. Its customization is to add, delete, change and check interface differences and some of the page customization function.
For the common parts, we can provide the page components mentioned above and provide a unified approach to data processing; The default logic can even be combined to form one large, complete business component.
For the customization part, if there is less customization, some customization capability can be exposed through business components. More often, you can only concatenate your own logic using the provided independent components. Therefore, the componentization of management console page can be divided into unified business components or basic page components to assemble logic.
Configuration change
The configuration information required by the management console page is similar to that of the browsing class, except that the page structure and page data are combined. In order to increase the generalization of the rendering engine, we unified the componentization of the two different scenes at the DSL layer.
First, to support common scenarios, we introduced custom layouts to express complex styles of pages. Secondly, we use jSON-Schema recursive data structure to identify the parent-child relationship of components. FunctionList is then introduced to express the events triggered by this component to establish component correlation. Finally, in addition to components, we have the JSAPI module to represent the page logic.
visualization
Such a complex DSL must not be directly exposed to the end user, so we provide a component designer in the visualization stage, where the business side developer can design the required large particle components on the component designer and then expose them to the end user.
In the visualization stage, in addition to the page design constructed in the browsing class page stage, we also provide data model design and component design.
The overall design of the data model is to meet the requirements of the unified add, delete, change and check interface. It consists of two parts, one is the uncoded generation of data model, the other is the low coded generation of logic. Its construction can be seen as a defining form. For a form, there are universal interfaces that can meet the interface capabilities of add, delete, change, search, sorting and filtering, etc., and customization can also be built through logic.
Component design needs to be emphasized here. For businesses with customization requirements, components can be modified and published to the component marketplace for use by end users in page design.
In the designer scenario, data model creation can be filled in with data model related information, form information, including form fields, field types, mandatory or not, etc. The new button creates this form structure in the background database.
In addition, we will preset a large and complete business component in the table designer, which can be modified on the business side. There may be cases where customized function is needed.
To the page design phase, the component market in addition to the original floor components, more UI components, process components, such as logical component choice, here you can choose to from the components released form designer, that is, the release components can not only through local IDE development, also can generate the page configuration, greatly shorten the release process.
Stage 2 Summary
HPA2.0 platform as a whole is still in demand iteration, many businesses have been connected, but the specific data has not been released yet. But in phase 2.0 we enhanced our DSL rendering engine so that complex purchase-class pages, such as the price calculator, went into the configuration phase, reducing the amount of code by 70% and changing times from days to hours.
In addition, while building low code generation for management desk class pages, we also realized low code/no code generation for data model, logic and other modules, and found that these capabilities can be used independently or in combination.
For example, you can use full functions: create a new application, start from new data structure, go to the configuration page, select the data source until published; Also can only be equipped with API module, fast exposure background interface; Or connect to their own data sources, configure only the page and publish, configure part of the page and integrate into the existing project, exposed as components, integrated into a single page.
conclusion
Low/no code is an inevitable result of the evolution of the front-end team, and each team should develop or purchase the industry’s low code platform according to their own team needs. In addition, the positioning of low code platform should be clearly defined at the early stage: whether to solve the pain points of the team’s own business or the subsequent commercial use. The former should be recustomized, while the latter should focus on generality, taking into account the needs of each business.
welfare
After watching the practice of front-end low code on huawei cloud official website, do you have any harvest or questions you want to communicate? Welcome to leave your questions or feelings in the comments section of [original]. We will extract 3, invite experts to communicate with you 1V1, and send a developer gift package.
This time, there are two Huawei experts to share the website high availability guarantee scheme and intelligent experience practice, they also answered the developers concerned questions, such as the best scheme of website high availability guarantee, intelligent content recommendation and so on. Please scan the code to watch the video. The full speech will be published in the cloud community later. Please stay tuned.
Finally, attached is the technology sharing PPT of Huawei front-end R&D engineer Guo Xiao at this Global Software Conference. Click “Huawei Cloud official website front-end Low Code Practice” and you can download and view it at the end of the article.
Click to follow, the first time to learn about Huawei cloud fresh technology ~