Author: Idle fish technology — Ye Yao
background
With the gradual disappearance of the c-end traffic dividend, the end of the external delivery has become one of the important business to seek growth. Different apps have different front-end containers in different application scenarios and in different periods:
1. Browser-based Webview container (H52. React Native, Weex container 3 derived from client rendering. The flutter container based on self-drawn rendering, 4. Small program container with platform opening capability
When the business is carried out outside the end, it needs the front-end students to evaluate and adapt to the target environment one by one. In the early stages, the front end is often supported by maintaining multiple implementations of the same business for different target environments, which multiplies the workload. Under the space of efficiency improvement, the cross-end scheme was spawned
Problem definition
In the front-end code of a cross-end business, there is usually a lot of repetitive logic for cross-end JS API calls:
If (isH5) {if (isXianyu) {webXianyuToast(); }else if (isTaobao) {// webTaobaoToast(); } else if(alipay){// alipay webAlipayToast()} //... } else if(isWeex) // ...Copy the codeThese calls typically take the path from development to going live:
1. Determine the target environment with business students. For example, H5 (Alipay, Taobao, Tmall, etc.) 2. Ask the target container maintainer about THE API call mode 3. Debug and develop in different environments. 4. Test students using different models on different apps
Each step is a time-consuming physical task. It is assumed that the usability, ease of use, richness, and extensibility can be met, so that the business can directly develop the following code, and then go online after normal testing. What problems should a cross-end API solution solve and what capabilities should it provide?
import toast from 'uni-toast'
toast()
Copy the code1.** Usability: ** suitable for Webview, small program, Wap and other front-end containers and apps commonly put in the business. ** Ease of use: ** let the API call in different environments have a reliable, fast debugging support of the unified entry 3.** rich: 4.** Scalability: ** With the development of the business, more APPS and apis can be supported; With the development of front-end technology, more forms of containers can be supported
Scheme design & implementation
The overall design
In the initial stage of the project, I learned that not only Xianyu, but also the whole Ali Economy front-end support cross-end business has the same problem. Therefore, the cross-end API project is promoted in the way of joint construction from the perspective of economy. Scheme design for the above problems:
• The specification acts as a cross-api flattening standard, making it possible to perceive only one set of upper-layer businesses. • The SDK follows the specification and flattens out the underlying API calls for different environments. By means of engineering capabilities such as custom build and end build, it reveals customizable and extensible cross-end API products. • Supporting facilities through API documents, CANIUSE tools to provide fast retrieval capabilities, one code multi-end call examples to provide quick trial capabilities;
To specification
The meaning of the cross-end API specification is:
1. Provide reference standards for THE API design of the SDK layer upward, and improve the certainty and rationality of the application on the business side; 2. Provide reference standards for Native layer JSAPI design downward, and slow down the trend of differentiation at the bottom layer;
Whether the specification can be widely promoted and maintain its vitality depends on its own rationality ** and upstream and downstream recognition **. In order to ensure the above two points, authors of existing cross-end schemes in the economy were invited to set up a cross-end API specification group, and the cross-end API specification was formulated from the following four aspects:
1. Determine scope: What apis should count as cross-end apis.
The cross-end API should have the cross-end attribute ** and the high-frequency attribute ** : the cross-end attribute can be objectively reflected by the support of each container, and the high-frequency attribute is judged by the call statistics of each scheme on the one hand, and the vote of the members of the cross-end specification panel on the other hand
1. Environment probe: The core of cross-end API is to implement according to different environment calls. Accurate environment awareness is particularly important.
Environmental judgment involves standard containers and special containers inside and outside the economy. In the environmental probe specification, a combination mechanism of container identification protocol, end identification protocol, system identification protocol and identification order agreement covers all scenarios.
1. Standard API definition: The standard API model is the interface of the real API and the skeleton of all apis.
Through the analysis of the standard API set, the differences between apis are mainly reflected in four parts: method naming, invocation mode, input and input parameter structure, and return error code, which together with the input and input parameter extension mechanism define the standard API model.
1.** Extension mechanism: ** Scenarios not covered by the standard API collection are supported by customization and extension capabilities.
Extending the new end container implementation based on the standard API, or extending an entirely new API;
The SDK to achieve
With the specification as the implementation basis and guidance, we started to implement the SDK. During the whole process, the main challenges were as follows:
[Implementation] ** Huge maintenance workload: ** adaptation and long-term maintenance of 55+ API on 8 containers and 30+ APPS, and there is no convergence trend in the number of APIS and environments ** [Engineering] Multi-scenario product Output: Multi-scenario use -> multi-form product. ** For example, the daily business development expectation is window.uni.toast(); Cross-end base material development is expected to import toast from ‘uni-toast’. The use of multiple scenarios makes the product need multi-form output [engineering] ** Customization of the solution: ** From the perspective of the economy, the scene is not only for xianyu’s own business. Business-side scenarios typically require only a portion of the container environment supported by the solution, and using the entire solution introduces unnecessary redundancy. So the solution needs to support the ability to build subsets from the full set definition
The key solutions to these challenges are:Layer ADAPTS API by end. API differences are distributed in the container layer and APP layer, and the SDK design is also smoothed according to the layers. The container layer smoothes out the general API differences, and the APP layer is customized based on the container layer. The end – to – end design brings naturalscalabilityWhen supporting a new end, you only need to implement the corresponding API adaptation set. The rest of the environment determination, mounting API, and multi-dimensional output package are left to the project and UNIapi-core.
** Custom build capability. ** The design of the atomization API + the combination mechanism enables the whole solution to have the ability to customize the build. Atomization API: The API adaptation on the specified container and APP is used as the smallest unit to achieve no side effects. Composition mechanism: the required API and target delivery environment are extracted through configuration, and the API is automatically combined to build and publish in the way of code template;
Construction of supporting facilities
The specification and SDK meet the requirements of usability, richness, and extensibility. In ease of USE, the cross-end API provides complex API query, debugging capabilities, the construction of internal, open source site: documentation (support information detailed to parameters, APP granularity), CAN I USE tool, one code multi-end invocation examples, etc
After the service is added
After the cross-end API scheme is added, the workflow of cross-end services is optimized as follows:
1. Centralized container capacity information maintenance, so that product and development students do not ask capacity one by one environment, but through a unified entrance to quickly query and evaluate 2. Unified multi-end API ADAPTS THE SDK, making the development students no longer piecing together, debugging and developing THE API one by one, but directly using 3 like the standard API. Unified maintenance of SDK eliminates the workload of testing the container capability of students in different models and environments
Since the RELEASE of SDK 1.0, xianyu will play community, sharing outside the end to undertake page and other businesses began to pilot and landing. In addition, the program SDK Uni API has been applied in 10+ BU in Ali Economy, gradually becoming the front-end development infrastructure of the economy.
Looking forward to
• Leveling is not the end, the upper level adaptation to differentiation is always the intermediate solution, a set of bottom standard API is the optimal solution. The Cross-end API Call Specification provides input from the upper layer usage side to the Container API standard so that new container apis can be designed with reference. • Open source community version (Universal-api.js.org\ [1\]) building (built by cross-end API group, Rax, etc.) At present, Uni API open source version has supported ali, wechat, byte, Baidu and other small programs and H5 containers. It is expected to continue to expand the RICHNESS of API and support containers in the future
So what do you think the next generation of cross-end solutions will be achieved by unifying the underlying Fuchsia OS, HarmonyOS and other multi-end operating systems, or will it still be achieved through upper-level adaptation, given that the end technology is still evolving?
References
[1] universal-api.js.org: universal-api.js.org/