「Yapi 改造计划一」多层级目录支持

100m

改造 Yapi 扁平管理逻辑，支持多层级结构管理。

改造原因

今天的内容是针对 API 管理结构进行二次开发，现在的扁平化方案随着业务的增长及 API 托管量的增长日渐吃力，在此基础上，我们需要在目录上做一些改动。

改造预期

需要改动的模块主要是接口列表部分，分类目录下管理的数据除 API 类型外，增加 目录 类型，且 目录 下可以继续管理 API 和 子目录，改造后，用户在使用时拥有较高的自由度，可以满足大部分场景。

改造前：

.
├── cat
│   ├── 1.api
│   ├── 2.api
│   └── 3.api
└── cat1
    ├── 1.api
    ├── 2.api
    └── 3.api

改造后：

.
└── cat
    ├── 1.api
    ├── 2.api
    └── dir1
        ├── 3.api
        └── dir1-1
            └── 4.api

数据结构改动后，需要对依赖的模块做产品逻辑兼容，

首先是接口列表的位置编辑功能，需要兼容的操作逻辑包括接口、目录顺序变更、层级移动，分类变更。
数据导入时，需在导入的数据中增加层级信息，并且支持导入目录，现行的方案会将 postman 的接口打平到一级目录下，丢失目录信息。
数据导出时，导出 swagger json 时，需要将数据层级打平，导出 json 时，保留层级信息。

改造过程

数据结构

增加目录类型：通过在 interface 数据 schema 中增加 interface_type 字段用于标记当前数据类型，0 标记接口，2 标记目录，目录类型的数据结构较简单，有效信息包括 title 用于标记目录名以及接下来提到的层级关系数据。

增加层级关系：在 interface 数据 schema 中增加 parent_id 字段用于记录父节点，增加 ancestors 字段记录当前数据的直系祖先数据，parent_id 用于查找直系子节点，ancestors 字段便于查找所有子孙节点，分类一级目录下的数据，parent_id 与 ancestors 值为空。

举个例子：

.
└── cat
    ├── 1.api(1)
    ├── 2.api(2)
    └── dir1(3)
        ├── 3.api(4)
        └── dir1-1(5)
            └── 4.api(6)

以这节点树为例，节点括号中标注为当前节点的 ID，各层级数据存储结构分别为（为了方便理解，仅展示上文提到的字段，其余通用字段略过）：

1
2
3

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, ancestors: ',3,5' }

逻辑兼容

数据管理部分涉及处理的逻辑比较复杂，另做一篇文章单独聊，今天先说节点位置编辑这部分，在处理这部分逻辑时，分两种情况处理

当前编辑节点无子节点时，更改分类只需要变更 catid 字段，更改所在目录只需修改 parent_id 和 ancestor 字段，无额外操作
当编辑的节点存在子孙节点时，第一点中所有的变更动作需要同步应用在子孙节点

优化方向

上面的改造半年前已经完成，这段时间，平台托管的数据量进一步增加，一个项目的节点数据愈加庞大，首屏加载或者节点操作的计算成本开始增加，导致用户能感知的卡顿，节点异步加载的改造排上了日常。没有最好的方案，只有当前最合适的方案

Yapi 是很优秀的一款 API 管理及 Mock 工具，日常开发过程中，可以用于接口管理规范化同时提升团队间的沟通协作体验，不过我们在使用过程中也遇到了一些问题，并且在预期时间内这些问题无法被官方版本解决，因此，我们决定在 Yapi 之上做一些改造，以满足我们当前的使用场景。我们会用系列文章聊聊我们的改造和优化详细内容。

文章目录