Author: Li Jundong

Transform Yapi flat management logic to support multi-hierarchy management.

Yapi is an excellent API management and Mock tool, which can be used to standardize interface management and improve the communication and collaboration experience between teams during daily development. However, we have encountered some problems in the process of using Yapi, and these problems cannot be solved by the official version within the expected time. Therefore, We decided to make some changes on top of Yapi to fit our current usage scenarios. We will talk about our modifications and optimizations in detail in a series of articles.

Revamping reasons

Today’s content is the secondary development of API management structure. The current flat scheme is increasingly difficult with the growth of business and the growth of API hosting volume. Based on this, we need to make some changes in the directory.

Transformation expected

The modules that need to be changed are mainly interface list. Besides API types, directory types are added to the data managed under classified directories, and API and subdirectories can be managed under directories. After the transformation, users have higher freedom in using the data, which can meet most scenarios.

Before modification:

. ├ ─ ─ the cat │ ├ ─ ─ 1. API │ ├ ─ ─ 2. API │ └ ─ ─ 3. API └ ─ ─ cat1 ├ ─ ─ 1. API ├ ─ ─ 2. API └ ─ ─ 3. APICopy the code

After transforming:

. └ ─ ─ the cat ├ ─ ─ 1. API ├ ─ ─ 2. API └ ─ ─ the dir1-name ├ ─ ─ 3. API └ ─ ─ the dir1-name - 1 └ ─ ─ 4. APICopy the code

After the data structure is changed, it is necessary to make product logic compatibility for the dependent modules.

  • The first is the position editing function of the interface list, which requires compatible operation logic including interface, directory order change, hierarchy movement and classification change.
  • When importing data, you need to add hierarchical information to the imported data and support the import directory. In the current scheme, postman interfaces are flattened to a level-1 directory and directory information is lost.
  • When exporting swagger JSON, the data hierarchy needs to be leveled. When exporting JSON, the data hierarchy information needs to be retained.

Transformation process

The data structure

Add directory type: By adding the interface_type field to the Interface data schema to mark the current data type, 0 to mark the interface, and 2 to mark the directory, the data structure of the directory type is simpler, and the effective information includes title to mark the directory name and the hierarchical data mentioned next.

Increasing hierarchy: In the interface data schema, the field of parent_id is added to record the parent node, and the field of ancestors is added to record the data of the direct ancestor of the current data. The field of parent_id is added to search the direct descendant node, and the field of ancestors is added to facilitate the search of all descendant nodes. For data in the level 1 directory, the values of parent_id and ancestors are empty.

Here’s an example:

. └ ─ ─ the cat ├ ─ ─ 1. API (1) ├ ─ ─ 2. API (2) └ ─ ─ the dir1-name (3) ├ ─ ─ 3. API (4) └ ─ ─ the dir1-name - 1 (5) └ ─ ─ 4. API (6)Copy the code

Take this node tree as an example. Nodes are marked with the ID of the current node in parentheses. Data storage structures at each level are as follows (for easy understanding, only the fields mentioned above are displayed, and other common fields are omitted) :

1.api: { interface_type: 0, parent_id: '', ancestors: ''} dir1-1: { interface_type: 1, parent_id: 3, ancestors: ',3'} 4. API: {interface_type: 0, parent_id: 5, rooted: ',3,5'}Copy the code

Logic is compatible with

The data management part involves processing logic is more complex, and I will talk about it separately in another article. Today, I will first talk about node position editing. When dealing with this part of logic, I will deal with it in two cases

  1. If the current editing node has no child node, you only need to change the cATID field to change the classification, and you only need to change the parent_ID and ancestor fields to change the directory
  2. When the edited node has a descendant node, all changes in the first point need to be applied to the descendant node simultaneously

To optimize the direction

The above transformation was completed half a year ago. During this period, the amount of data hosted by the platform further increased, and the node data of a project became larger and larger. As a result, the computing cost of first-screen loading or node operation began to increase, leading to the delay perceived by users, and the transformation of asynchronous node loading became routine. There is no best solution, only the most appropriate solution at the moment