Abstract:From browsing page to management page, see how Huawei cloud official website builds low-code platform in stages according to business scenarios to improve the efficiency of page iteration.
This article is shared from the Huawei cloud community “Huawei cloud official website front-end technology evolution and low code practice [Global Software Conference Technology Sharing]”, the original author: technology torchbearer.
Front-end team evolution often goes through the 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 how to build a low-code platform in stages according to business scenarios and improve the efficiency of page iteration.The following is a shorthand of the speech.
Three major challenges facing front end teams
Why the word low code is so hot recently, in the recent QCON conference there are more than 5 low code related to share, the root cause is still some problems encountered by the front-end team in recent years.
The first is the surge in the number of pages. According to a presentation by IDC at the China ICT Market Trends Forum 2020, the development of the digital economy will generate more than 500 million new applications/services in the last few years, which is equivalent to the number of applications created in the last 40 years. The rapid development of the digital economy requires the transmission of massive information, and the front-end page as an important way to transmit information, the number is also surging.
Followed by the front shortage of manpower, chat early conference recently for 535 team leaders, according to a survey of these teams years expectations for a total of more than 9000 front-end, but actually to about 5000 people, only less than 60% of the expected, and from the data of talent market, the front-end human growth from 14 years begin to decline gradually, The new blood on the front end is decreasing year by year. Demand has increased, manpower has been flat or reduced, the problem is very clear.
Finally, the operation and maintenance pressure brought by the surge of demand. Most of the front-end business demands come from operations and products, and the strong correlation with the business leads to the instability of the demand. An online page is likely to have to go through the online release process again with a minor adjustment, which can be time-consuming and costly. Moreover, after too many pages, some of the traditional content quality inspection through manpower will be very difficult, the quality of the online page is difficult to be guaranteed.
So, in this context, how does the team evolve technology?
The Road to Technology Evolution: From Slash-and-burn to Visualization
In the beginning, the front end was in the primitive “slash-and-burn” stage, where pages could be stacked as long as there were three bases of HTML, CSS, and JS. Gradually, we began to extract some common methods into the method library, the common components into the component library, and combined with the engineering idea to reuse some modules, that is, the componentization stage. During this period, code is still being written, but the reuse of code begins to improve the efficiency of the project.
In the late stage of componentization, we found that in many business scenarios, some components were often combined together, and business components began to appear in component libraries. For example, a page will often have a floor with a main heading and a subheading in the middle of the top, and a few cards at the bottom, each with a background image and a description. So let’s build such large granular components that are easy to reuse.
As component granularity increases and the number of business components increases, the amount of code required to create a simple page requirement becomes less and less. It is often just a matter of quoting a few components and passing some parameters, because a lot of logic is already encapsulated in the components. At this point, we write the components and parameters to the configuration file, and then we write a set of parsing logic (the rendering engine) that parses the contents of the configuration file into object code. In this way, the following only need to maintain a configuration file, initially entered the stage of configuration.
In the configuration phase, DSLs are written without the need to be aware of technology stacks and business processes, and the final rendering is completely controlled by the rendering engine. At this point we can expose the maintenance rights of the profile to the application developer: we maintain the rendering engine, the component library, and the application developer maintains the profile. 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 for the sake of the application experience, we can provide a page for users to drag and drop components and edit, converting the results of the user’s actions in the interface into a DSL, so that the end user can generate the final page without knowing the DSL. The simple operation makes it possible for non-developers to grasp it, so it gradually becomes a situation where everyone’s needs are implemented by themselves.
It can be seen that in the development process, we constantly extract the common capabilities and abstract the business process, and finally achieve the low-code, no-code capability opening, which greatly reduces the maintenance pressure of the front-end team.
There are many examples of similar evolutions in the industry, so low code is slowly coming into view.
How to select low code platform?
Low code started early overseas, and the concept was first put forward overseas. OutSystem and Mendix and other companies’ low code platforms have already taken up most of the market. China is a late developer. The first commercial low-code platform was launched a few years ago, but now there are hundreds of competing ideas, including Huawei’s AppCube.
Low code is “low” in two ways:
Low code not only means less code is written during the development process, but also means lower overall process costs such as application deployment costs.
Second, the technical threshold of application production is lowered, the underlying business logic and the shielding of the technology stack enable non-professional developers to quickly put into application production after simple IT training.
So how does a front-end team choose in this wave of low code?
The first step is to see if the front-end team necessarily needs a low-code platform. It is estimated that more than 95% of the scenarios of small and medium-sized enterprises can be built with low code platforms, while more than 70% of the scenarios of large and medium-sized enterprises can also be built with low code platforms. As we mentioned earlier, low code is an inevitable consequence of the evolution of front-end team technology, so a low code platform is necessary.
The question follows, is the direct purchase use or self-research? We compare from three dimensions: scalability, ease of use and labor cost.
In terms of expansion and ease of use, if you buy industrial platforms, you can only use the platform capabilities exposed by them. Although the platform will open some customization capabilities, it cannot meet the needs of the complex business of Huawei’s official cloud website. In terms of cost, the platform of the whole process from development to on-line includes the construction of data model, UI, logic and process with low code and high labor cost.
If the team size is small or the business scenario is relatively unified or the team is still in the componentization stage, I suggest using the industry platform, such as AppCube of Huawei Cloud, to save time and effort.
But if the team is large, the business scenario is complex, and the team evolution is already in the configuration or visualization phase, it is better to develop your own in the long run. Because when enterprises or organizations develop to a certain extent, they will gradually give up all kinds of outsourcing components and build their own research capabilities to adapt to the needs of their own organizations.
For our team, considering that the importance of scalability is higher than the human cost, we choose to develop a set of low code platform.
How does Huawei cloud official website carry out low code practice?
Huawei cloud official website low code practice
The official website of Huawei Cloud mainly contains three types of pages:
Browse pages, such as product introduction page, document page, such pages are characterized by floor as the dimension, page components are mainly cards, text, pictures, floors are independent of each other, interaction is less, language is based on XTPL.
Management desk pages, such as bill center and internal management page, are mainly chart pages, and the interaction of such pages is relatively fixed, including search, addition, deletion, modification and search, etc., and the language is VUE.
Purchase pages, such as activity pages and price calculators, mostly present product specifications. The page interaction is more complex and the language is also Vue.
Among them, browsing class and management desk class pages account for more than 90%.
In the practice of low code, the overall goal of Huawei’s official cloud website is to realize an efficient application production platform for operators and developers, which is called HPA internally. The functions of the platform include but are not limited to low code or no code generation of data model, logic, UI and process.
According to the business background, we will initially divide the goal into two stages. The first stage is to realize the codeless generation of browsing pages; at the same time, we will build the platform capability to realize the codeless generation of pages from production to release.
In the second stage, the codeless capability of the platform was enhanced for the management desk type pages, and the low code generation of the page was extended to data model, logic and process dimensions.
Stage 1: Browse class pages with low code
The first low code is browsing class pages, because the number of such pages is large, the cost of manpower is large, and the page composition is relatively simple, the cost of low code is relatively low. The way we build UI low code is componentization, configuration, and visualization.
componentization
Among them, the key to componentization is to deal with the commonality and customization of the page. The commonality of the browsing page is the dimension of the floor, and the floor is independent. Customization is that some pages will have some non-floor components, such as floating Windows or a little global logic.
We first classify pages according to different customizability to form some page templates, such as general page template and some other product page, news page template. Page templates often contain the header and footer, as well as the page customization logic mentioned earlier. For example, the official website service support page uses a generic page template that contains only the footer.
Then to deal with the common part, we split the page according to the floor, the official website service guarantee page can be composed of 5 types of components, component 2 and 3 are step bar components, can be reused. We incorporate the customizability of the page into different page templates, and the common part is the components of each floor that can be reused.
Configuration change
Once componentized, this is how the page is described with configuration information. The configuration information contains the page template, page structure, page data and dependency information.
Page templates describe header, footer and page customization information. The page structure describes which floor components are used and in which order. Users are modifying the page structure file by dragging and dropping components on the canvas or deleting them. The page structure also records the relationship between the floor components and the page data.
The page data is the specific configuration data that describes the floor components. The user edits the component content on the canvas, which is to adjust the page data.
Finally, add the version dependence information of floor components and tripartite components, and then use the DSL rendering engine to render the final HTML page
visualization
Once the page is configured, consider how the end user generates the configured information through the interactive interface.
The following diagram shows a schematic of page structure editing, which drags and drops components from the Component Marketplace on the left side of the canvas to a specified location on the page, and page data editing. Components in the component market are developed via a local IDE and then published and uploaded via NPM. Page data editing is performed in the component editing box that pops up after clicking on the target component. The component editing box is defined in the component with the syntax similar to JSON-Schema. After the completion of editing, you can choose to publish, preview and other functions.
Page access
At publication time, the canvas stores the page configuration data to a back-end database, which is subsequently invoked through the Unified Data Microservice.
When visiting the current network, if the CDN fails and goes back to the source, BFF will use unified data micro-service to obtain the page configuration of the current page according to the page URL, including the page template, page data and dependency information. Then the corresponding floor component content is obtained from OBS according to the dependency information, and the final page is rendered according to the DSL rendering engine mounted by BFF.
The difference between the preview state and the run state is whether there is a CDN, and then the data information is sent to the BFF from the front end, so there is no need for the BFF to unify the data microservice.
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 are also important.
The module diagram of HPA platform made in the first stage mainly has four layers.
The infrastructure layer is Huawei cloud cloud service, database RDS, cloud search CSS, object storage OBS, Redis, distributed message notification, and one-stop AI development platform ModelArts.
The micro-service layer provides user rights management, with workflow, message notification to specify which pages the user can edit, and who needs to review after editing; Content quality check and grayscale test as the quality and style of the page before going online; Content management is the Unified Data Micro Service Interface mentioned above.
The middle tier of the data is the BFF that returns the rendered page based on the URL or call parameters.
The front-end canvas layer mainly includes component market, asset management, application management, version management and page editing. Application management here is narrow and limited to the UI. Version management function mainly provides the page back, contrast and other functions.
Stage 1 Summary
After HPA1.0 came online, it has achieved remarkable results. We currently maintain about 100 floor components, and some customized floor components, which basically cover all the browsing pages of the official website. The reduced workload on the development side can also be seen from the usage of operations, with operators making about 6,000 self-help changes in the platform on average.
In addition, the release process is also greatly simplified, and many changes do not need to be passed through the requirements to the development and then to the test online, and can be operated independently, from the day level down to the hour level. Finally, the automatic and comprehensive content review also greatly improves the quality of the page.
While achieving obvious results, we must also note that there are still some points that can be optimized. For example, DSL is to render browsing page, the scene is relatively simple, then the subsequent processing of 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 release cycle is still relatively long. Finally, lack of codeless process orchestration capability, if the new permission group configuration process is complex.
Therefore, we continue to enter the second stage, with the management desk page low code as the business purpose, enhance the platform capability.
Stage two: management desk class page low code
componentization
The management desk page is a kind of page type which is supported more by the low code platform in China at present. The following figure is a simple management desk page example, and part of the information in the figure is hidden.
The body is a table with paging components at the bottom, add and search at the top, and search, change, and delete buttons inside the table. Pages are characterized by the relatively fixed types of components, such as tables, search, pagination, pop-ups, buttons, and graph components. And the basic logic is relatively fixed, which can be generalized to add, delete, change and check the underlying data model. Its customization lies in adding, deleting, changing and checking interface differences and some customized page functions.
For common parts, we can provide the above mentioned page components, and provide a unified data processing method; It can even be combined to form a large and complete business component by default logic.
For the customization part, if there is less customization, some customization capabilities can be exposed through the business component. More than that, you can only use the separate components provided to concatenate your own logic. So the componentization of management desk pages can be divided into using unified business components or using basic page components to assemble logic.
Configuration change
The configuration information required by the management desk page is similar to that of the browsing class, but the page structure and page data are combined. In order to increase the generalization of the rendering engine, we unify the components of the two different scenes in the DSL layer.
First, to support common scenarios, we introduced custom layouts to express complex page styles; Secondly, we use the JSON-SCHEMA recursive data structure to identify the parent-child relationship of the components. Then we introduce FunctionList to express the events triggered by this component to establish component affinity. Finally, in addition to Components, we have the JSAPI module to represent page logic.
visualization
Such a complex DSL cannot be directly exposed to the end user, so we provide a component designer in the visualization phase, where the business side can first design the required large granular components in the component designer, and then expose them to the end user.
In the visualization stage, we provided data model design and component design in addition to the page design built in the browsing class page stage.
The overall design of the data model is to achieve a unified interface for adding, deleting, modifying and checking. There are two parts in it, one is the code-less generation of data model, the other is the low code generation of logic. Its construction can be seen as a definition form. For a form, there are common interfaces that can meet the interface capabilities such as add, delete, change, search, sort and filter, and can also be customized through logical construction.
The component design needs to be emphasized here. For businesses with custom demands, they can modify the component themselves, and then publish it to the component market for end users to use in page design.
In the designer scenario, data model creation can fill in data model related information, form information, including form fields, field types, whether required to fill, etc. When you add a button, the form structure is created in the background database.
In addition, we will preset a large and complete business component in the form designer, and the business side can modify it on this basis. There may be cases where we need to define a custom function.
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
The overall HPA2.0 platform is still in demand iteration, and many services have been connected, but the specific data has not been released yet. But in 2.0 we enhanced our DSL rendering engine, making complex purchase pages like price calculators configurable, reducing the amount of code by 70%, and reducing change times from days to hours.
In addition, while building the low code generation of the management desk class page, we also realized the low code/no code generation of the 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, from the new data structure, to the configuration page, select the data source until release; It can also be equipped with only API module to quickly expose the background interface. Or docking with your own data source, just configuring pages and publishing them, configuring some pages and integrating them into an existing project, exposing them as components and integrating them into a single page.
conclusion
Low/no code is an inevitable result of the evolution of the front-end team. Each team should develop or purchase the industry’s low code platform according to its own team needs. Moreover, the positioning of the low code platform should be clear 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 re-customized, while the latter should be re-universal, combining the needs of each business.
welfare
After reading the front-end low code practice on the official website of Huawei Cloud, do you have any harvest or questions to communicate? Please leave your questions or thoughts in the comments section of [original]. We will select 3 items, invite experts to communicate with you 1V1, and send a developer gift package.
In this time, there are also two Huawei experts to share the website high availability guarantee scheme and intelligent experience practice. They also answered the developers’ concerns, such as the best scheme of website high availability guarantee, some tips on intelligent content recommendation and so on. Please scan the code to watch the video. The full text of the speech will be posted on 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 [Practice of front-end low code on Huawei cloud official website] for download and view at the end of the article.
Click on the attention, the first time to understand Huawei cloud fresh technology ~