Unconsciously, Ali has been working for one year. During this year, I have been exposed to development technologies such as Low Code, small program, MOBILE TERMINAL H5, monitoring and PC desktop (CEF & Electron). In these technologies, the PC desktop side hybrid development technology is relatively precipitation more, the next will share with you some desktop side development thinking, I hope to enlighten everyone’s daily development.

Tips: If you are not familiar with desktop technology, check out the 2019 Front-end Annual Summary/Desktop Development. In addition, the desktop development technology described in this article does not adopt novel Flutter technology. If you are interested in the construction of Flutter technology inside Ali, you can check out how to systemize Flutter construction inside Ali Group.

The basic concept

I’ll start with some basic concepts for desktop development. There are some instructions that will not be used throughout the article, but some of them will help you understand the framework instructions that follow.

Hybrid development

The desktop development described in this article mainly uses a Hybrid development mode (a development mode in which a Web browser is embedded in a native application container), which combines the advantages of Natiive and Web development. In some high-performance business scenarios (such as IM chat, audio and video, live broadcast, etc.), Native can be used for development, while in some business scenarios with relatively frequent function iterations, Web can be used for development (low development cost). In addition, Web development is relatively good at cross-platform, animation, dynamic, rich text orchestration and so on.

CEF container

The Hybrid development explained in this paper mainly adopts Chromium Embedded Framework (CEF) technology, and its main features are as follows:

  • HTML5 compatible Google Chromium browser can be embedded in Native apps
  • You can create lightweight application containers (CEF containers for short) that are primarily used to host user interfaces developed using Web technologies
  • Can support cross-platform (Mac, Linux & Windows) development, and easy to customize and integrate other types of Native applications
  • Google Chromium updates will be tracked in real time, enabling Web development to use some relatively new features
  • C and C++ language for development and design, and can be closely combined with Google Chromium browser
  • Specific versions of CEF can support running desktop applications on Windows XP

Note that the CEF container can simply be understood as embedding the Google Chromium browser in a native application environment. In addition, desktop applications can be developed in multi-window mode, and each window can host at least one Web front-end application (sub application for short). If multiple sub-applications want to communicate, they can use the QUERY parameter of URL (low real-time requirement) or publish and subscribe mechanism of Native bridge technology (high real-time requirement).

Tips: Many students are confused about the difference between Google Chromium and Google Chrome, which is worth checking on Google.

JSBridge & Native API

The front-end development environment is sandboxed by the browser, limiting the use of some of the operating system’s security-related capabilities. In the mixed development of desktop, it is inevitable to use the Web front end to tune up specific system capabilities. At this time, a Bridge technology between Web and Native is needed, which is called Bridge, as shown in the figure below:

Warm reminder: the picture is provided by my colleague, but the specific source is not found.

You can think of the left side of the diagram (the self-drawing engine development framework) as simple Native development and the right side (the pan-Web container framework) as Hybrid development. It can be found that if the Web front end wants to bypass the sandbox limitation to tune up the Native view components and system capabilities, it needs to use the Bridge technology provided by Native. Native applications can invade JavaScript syntactic environments in CEF containers, so they can be bridged by injecting apis (Native apis for short) into JavaScript environments (such as window global objects).

Tip: In addition to the desktop hybrid development model, a similar hybrid model exists on the mobile side, where the Web front end is often referred to as H5 technology. In addition, the bridge technology allows the Web front end to invoke system capabilities indirectly through Native, so there will be some performance loss.

JS API

In addition to developing its own applications, Ali desktop will also provide a service platform for external ISVs to carry out tripartite application expansion. At this point, it is necessary to open Native API capabilities (involving some versions of calls and authentication matching processing). These open apis, referred to as JS API, are more abstract in capability compared with Native API. In addition, they also need to be cross-platform and cross-application, as shown in the figure below:

Tips: Ali will theoretically close down any technology you can think of, JS API is no exception.

HotFix

On the desktop side of native apps, fixing bugs in the online version or iterating on new features is often accompanied by a new release. HotFix fixes online bugs without releasing the version of the application and without users’ awareness (or by prompting users to manually update the patch package). The general implementation process is as follows:

Warm tip: The picture is from the thermal repair platform construction in the big front-end era.

If you want to fix the bugs of the Web front-end application in hybrid development, you can at least skip the desktop restart step. Meanwhile, offline Web front-end resources can be updated in the form of resource delivery, while resources in the form of CDN only need to push the new version of resources (generally, these things will be grayscale by level to ensure the stability of update).

Desktop development

During ali’s one year, the development of desktop side mainly went through the following stages:

  • Learn about existing desktop side frameworks
  • Develop new subapplications within existing frameworks
  • Optimization of the desktop framework exploration
  • Design and implement a new desktop framework

Understand the desktop framework

After a simple popularization of desktop side technology in the early stage, I have a deep understanding of the existing desktop side framework, as shown in the following figure:

The framework mainly consists of container layer, general layer and application layer, with the following characteristics:

  • All sub-applications are developed and maintained in the same repository
  • Webpack multi-entry configuration, Webpack multi-process processing and development configuration
  • The technology stack used when adding subapplications is limited by the framework
  • Using TypeScript for business development, robust
  • Rxjs (Action event stream) combined with publish and subscribe for event processing
  • The React Router is not used. Simple page switches are handled by state management

Develop new sub-applications

At the beginning of the client terminal application development, although aware of the complexity of the framework structure, but did not think of the framework can do some optimization work, just on the basis of the original framework for local optimization of the application layer. Due to the limitations of the framework, React Hook and some new features of JavaScript cannot be adopted, and the code design is relatively unable to achieve a flat structure. At that time, some sub-application layer code structure optimization was considered, as shown in the figure below:

The business layer

As you can see from the desktop framework and the mind map above, there are some simple changes to the existing application layer. The function of the original business layer itself has no hierarchy, which is a development mode without hierarchical thinking mode. In the early stage, when continuing the old sub-application thinking mode, I found that the code structure could not adapt to the frequent changes brought by requirements, so I decided to adopt the business layer layered design mode after thinking about it:

  • Layout: It can quickly respond to changes in service requirements and reorganize service modules, with good scalability
  • Container: encapsulates high-order functions and distributes application data and behaviors of service modules
  • Service module: A modular separation of services. Specific communication data is designed between modules

The advantage of such a hierarchical design is that requirements can be adjusted only at the layout level when they change arrangement.

MVC constraints

Build a common data layer (Model) to drive business layer (View) updates, and the container in the business layer acts as a Controller. In addition, when the business becomes extremely complex, the data layer will become relatively difficult to maintain, and the control mode of classification is adopted here:

  • View data: rendered view data processed by the data adaptation layer
  • Communication data: used for linkage processing between service modules
  • Request status: Used to cache request parameters, cursor/paging response information, and request status identification (default view, Loading, and request error processing)

It should be noted that view data will increase with the increase of business complexity, and the association between view data and view is more and more complex, which may lead to repeated rendering. PureComponent or shouldComponentUpdate can be implemented using immutability-Helper. (See the official document Optimizing React The Performance).

Warm tip: Many students write codes that strongly rely on the interface data of the back-end. Once the data of the back-end is out of control, it is easy to lead to the blank screen of the front-end page. In order to improve the robustness and maintainability of the code, an adaptation layer for back-end data processing is added to the data layer to decoupled back-end data from the front-end view. You can use the Optional Chaining syntax supported by ECMAScript Proposal Stage-4 to process the data. If the compiler environment does not support this new syntax, you can use the Lodash get tool method.

Desktop framework optimization exploration

In the process of developing sub-applications, I gradually realized some pain points of the old client framework:

  • Complex Webpack multi-entry configuration and redundant development configuration
  • Despite the use of Parallel – WebPack, application compilation speed is slow, reducing the development efficiency
  • There is no Hot Reload capability, which reduces the development efficiency
  • Features of newer React versions, such as React Hook, cannot be used
  • New versions of JavaScript & TypeScript features such as Optional Chaining cannot be used
  • The hellish nesting of higher-order functions in the business layer/container makes code bloated and complex, which is not good for code maintenance
  • The Rxjs publish-subscribe and action-flow mechanisms of simple sub-applications are not conducive to code maintenance
  • The common code such as business components in the common service layer and material layer is not decoupled
  • .

The local optimization of some frameworks is roughly envisaged:

As can be seen from the figure above, Monorepo structure is newly added on the basis of the original framework. The features of this framework are as follows:

  • Decouple Webpack configuration, optimize multi-entry configuration into single entry configuration, improve compilation efficiency
  • The application layer can be partially decoupled and some new environments can be configured to use new features
  • Common capabilities such as Native apis, business components, and common services can be decoupled

Some general-purpose capability building was considered, but true decoupling was still not possible for sub-applications. In addition, Monorepo itself does not reduce the cognitive and maintenance costs of the application, so this framework is not adopted. The design thinking of this framework establishes the thinking mode of decoupling application.

Tips: Monorepo development tools include Nx, Lerna and so on. To learn more about Monorepo in practice, see Vue CLI 3 for UI framework design with Lerna.

Technology of precipitation

Desktop framework optimization practice

In order to fully decouple the sub-applications, the new sub-applications are not developed and maintained in the warehouse of the original application, but are independently developed and maintained using the group’s engineering scaffolding capabilities. In addition, the desktop terminal application common template capability is added on the basis of scaffolding, which can be quickly generated by CLI command with one key:

Briefly introduce the engineering capacity building:

  • Group scaffolding: simple understanding asreact-scripts, can support applications, components and small programs and other development modes
  • Engineering monitoring: used to monitor and report compilation performance and error information of scaffold during development and use
  • Webpack customization plug-in: Used to customize desktop terminal applications for special compilation requirements
  • Sub-application development template: Integrates basic desktop development capabilities
  • Template pull: You can use the CLI command to obtain and generate a common development template type

The structure of the sub-application development template is roughly as follows:

Here is the general capacity building:

  • ErrorBoundary: View blank screen processing (display error view of bottom pocket), and monitor and report blank screen processing
  • Hook: Multi-terminal customizationHookAbility to
  • Request: multi-terminal request library, which can handle caching and Loading optimization (no Loading, request data caching, etc.)
  • Utils: generic utility functions

Note that the sub-application development template here does not have dynamic plug-in capability, but is a relatively fixed desktop development template.

Tips: The multi-terminal here refers to small programs, H5, PC clients (Windows, Linux, Mac), etc., which is a general construction proposition.

After the decoupling of sub-applications, the optimized framework of desktop mixed development is shown in the figure below:

The optimized framework features are as follows:

  • Added engineering monitoring capability, which can quickly perceive the development efficiency of each sub-application
  • Webpack configuration is maintained by engineered scaffolding
  • Improved compiling speed and Hot Reload capability
  • Use the latest React, JavaScript, and TypeScript features
  • Transform the multi-level development structure optimized by the sub-application pilot into a flat development structure (removing the container capability of higher-order functions)
  • Request caching, Loading optimization, ErrorBoundary fault-tolerant processing of view and other experience improvements
  • View white screen monitoring capability
  • Truly decoupled sub-applications can be customized for client applications

In addition, a new build layer is added on the basis of the old framework. Since the optimization of the framework decouples the sub-applications, the construction products of all sub-applications need to be combined (become the offline products of the Web front-end in the client installation package), and each sub-application contained in the combined products also needs to be version-mapped to the client. Therefore, the construction layer is added to deal with the version mapping relationship of each sub-application and the collaborative processing of cloud construction. Here, Jenkins, Node and Shell are adopted to carry out the online construction and product merger processing of each sub-application.

The future planning

Although some work has been done to optimize the desktop framework and the development efficiency has been greatly improved, it also increases the cognitive and development co-costs. In addition, the build layer is too thin, and there is still a lot of room to play in addition to the build itself. Here are some rough plans for the future construction of the client.

Document center

The establishment of a document center for desktop development can help developers quickly understand the technology and business background of the current desktop without knowing anything about it. The document center will be roughly divided into the following contents in the future:

  • Development of guidelines
  • A business that
  • Technical planning
  • Specification document
  • The business progress

The development guide is the focus, which will probably include the following contents:

  • Introduction of the development of
  • Basic concept
  • The overall framework
  • Project template
  • The development tools
  • Development and debugging
  • Version of the specification
  • Online build
  • Online fault

Build optimization

In addition to cloud construction itself, the construction layer can also achieve the closure of sub-application development specifications, as shown in the figure below:

Online detection capability will be added, mainly including:

  • Specification: whether the version, engineering template, etc. conforms to the development specification
  • Framework: Relatively important library versioning
  • Resource size: Detects the size of the resource build
  • Ability: detect access monitoring, service management, and internationalization ability
  • Code quality detection: detection of Optional Chaining and other easy to cause white screen syntax…

Process collaboration is mainly to improve the efficiency of construction, and construction processing can be carried out quickly in some closed loops related to r&d processes. For example, code submitting a specific commit message or publishing a specific branch in Gitlab can trigger the build (similar to Github Actions). Of course, the triggering layer involves not only Gitlab, but also many internal R&D collaboration platforms of Ali.

Research and development services

R & D service is a tool service platform that can get through the whole R & D link. For example, building the dashed box at the top of the optimization framework is a very important link. In addition, it can also access engineering ability, R&D performance data market, business monitoring data market, process coordination and HotFixed ability.

Research and development service is the basic service to get through the whole research and development link of desktop (also can include small programs, H5 and other applications) in the future. At the engineering level, it can integrate capabilities similar to VUE UI and flexibly integrate existing sub-application templates with plug-ins, which can quickly adapt to the R&D requirements of various business scenarios. In addition, the whole R&D link from application creation, requirement review association, requirement change, branch management, requirement development, cloud construction, defect association, gray scale and release can be completed in the R&D service platform, so as to achieve the integration of engineering system, process collaboration and construction.

reference

  • 2019 Front-end Annual Summary/Desktop development
  • How to systematize Flutter construction in Alibaba Group?
  • Thermal repair platform construction in big front-end era
  • Browser sandbox model
  • Introduction to H5 Mobile App development: Concept Chapter
  • IaaS, PaaS, SaaS differences
  • Vue CLI 3 combines Lerna to design UI framework