Gateway Project 部分 Review

[Shadowmaple]

项目

• 获取项目列表 getProjectList.go：

  是否分页其实不用客户端单独传一个参数来判定，根据 page 判断就可以了，比如 page 没传或是 -1 什么的，就表示不分页

• 删除项目deleteProject.go：

  项目名应该不用由客户端来传，应该自己根据 id 来获取 project name，或是直接从删除接口返回的数据中获取

• 修改项目信息updateProjectInfo.go：

  userCount 是项目的人数，不应该由客户端传的值来更改，而是通过计算 member 人数得到，而且 project 该接口也并没有用到 userCount 这个传过去的值，所以应当把这个移除，gateway 和 project 服务都要改。

• 获取项目成员getMembers.go：是否分页的问题，和 “获取项目列表” 那个一样

• 编辑项目成员updateMembers.go：

  1. 项目新增成员时，添加的动态应该是新加入成员的动态，如：小明加入了项目xxx
  2. 和“删除项目”的一样，项目名也应该由 id 来获取，如果参照客户端给的值的话，那容易造成数据不一致
  3. project 服务的接口参数有问题，成员 id 列表的类型应该是 uint32，而不是 string，需要改下

文档&文件

• 修改文件树updateFileTree.go：

  应该不需要新增 feed，修改文件树是在增加或删除文件操作之后的，feed 就是增加或删除文件。（不太确定）

• 修改文档树updateDocTree.go：和上面的一样

• 创建文档createFile.go：

  feed push 参数有问题，缺少 project name、创建的文档 id，文档 id 应该是从文档创建的接口 response 中获取，需要修改对应的 RPC 接口

• 修改文档信息updateDoc.go：feed push 同样的参数问题

• 删除文档deleteDoc.go：doc name 同样应该由 id 获取。feed push 参数缺少项目 id 和 name。

• 创建文件createFile.go：

  请求参数有问题，客户端传的参数应该只是文件、项目 id、文档夹 id，而不是包括文件 URL、文件 id 等等参数。该逻辑是后端需要把这个文件先传到 OSS 上，再把这个 OSS URL 存入 DB 中。或者分为两个 API，一个负责上传文件，一个根据文件url在DB中创建文件。

• 删除文件deleteFile.go：

  fileName 根据 id 获取，而不是客户端传的值。feed push 的参数有问题，缺少项目 id 和 name。

以下 API 都缺少 handlers 和 RPC interfaces

• 项目部分：
  • 创建项目
  • 项目回收站：查看，删除
• 修改文件信息（文件名）
• 文档夹&文件夹
  • 文档夹：创建、修改、删除
  • 文件夹：创建、修改、删除
• 评论部分
  • 文档评论：创建、获取、删除
  • 文件评论（目前未用到）：创建、获取、删除

可能还漏了其它的 API

权限问题

需要管理员及超管才能请求的 API 有：

• 创建项目
• 修改 project 信息
• 编辑 project 成员
• 文档夹/文件夹的删除
• 项目回收站的删除

只有超管才能请求：

• 删除项目

允许管理员、超管和 object 所有者可以操作：

• 文档/文件的删除和修改
• 评论的删除
• 文档夹/文件夹的修改

对于一些 API 需要加上特定的权限。对于管理员或超管的部分，直接加上写好的中间件就可以了（adminRequired、superAdminRequired），而对于 object 所有者，可能需要在 handler 中进行权限鉴别。

其它

• 注释
  • 函数注释依照 // 函数名 ... 的代码风格要求（已改部分）
  • router.go 中无用的注释去掉
  • 返回的 response 最好加上注释，尤其是一些比较难理解的字段，让客户端人员容易理解。
• 命名规范：
  • Go 变量驼峰命名，json 下划线命名。命名上，gateway 和 project 服务都有一些字段需要更改。既然是重构，那就尽量做到最好，从一开始就把这个问题解决了，不要留到以后。
  • 结构体字面量尽量大驼峰命名
  • 尽量不要自己创造缩写，容易造成疑惑，命名长一些没关系，关键是可读，比如 pid 就改成 projectID
• 写结构体成员 json 标签时会漏掉完整的双引号，比如 json:logo"，需要注意下（已改）
• query params，path params 这些获取失败返回的错误不应该是 errno.ErrBind，应该是 ErrQuery 或 ErrPathParam 之类的，Bind 是专门用于 body data 的，三者要区别开来。

[zxc0328]

的确，Project 这边，其实 Project 服务本身还有很多不完善的地方。主要是：

RPC 接口缺失（综合了上面的，去掉了一些暂时没需求的）：

• 文档的评论 CRUD。文件的暂时不做。
• 文档夹的 CRUD
• 文件夹的 CRUD
• 创建项目
• 项目回收站：查看，永久删除回收站里面的东西，恢复回收站里面的东西

RPC 接口未完成：

• deleteFile/deleteDoc：接口未完成。因为之前是打算用 GORM 的软删除字段 delete_at 去做。但其实之前工作台因为有回收站的原因，也有软删除，就是 re 字段。这个字段是 1 就代表在回收站（被删除了）。所以文件和文档的删除就直接修改这两个参数就行，不然要去迁移线上数据，有点麻烦。
• deleteProject：这个之前没有用 re，那就用 GORM 那个软删除字段就行。需要对表加字段。
• UpdateMembers：这个还没实现。就因为前端给的是一个新的成员列表。我们需要对目前的成员和新成员做一个 diff，看哪些人是新加的（需要在表里添加记录），哪些人是删除的（需要在表里删除记录）。这里注释还说要给 user 和 project 的关系表加一个联合索引，我觉得也是需要的。

以上的 SQL 变更和之前 status 那边的 like 表新增等等，都需要写到隔壁的 SQL 升级需求里面做记录。然后也需要在项目里面写一个 update.sql，作为代码存储在仓库中。

[zxc0328]

文件树存储的设计说明 以及 修改建议

之前版本工作台，我做了一个错误的设计。就是把每个项目的文件（文档）树（文件夹和文件之间的父子关系，最后构成一个树），作为 JSON 存储。然后对这个文件树的修改是前端来做 CRUD。

这种做法其实是有很大问题的。比如文件增加或者删除的时候，文件插入到文件树中应该也是需要一起完成的写操作，是一个事务。但如果把这个东西放到前端（emmm 其实也是可以做成事务保持一致的，但会比较蛋疼，因为这样就需要把创建文件的 API 的参数里面，又要文件本身信息，又要完整的文件树 JSON 信息。

这个 JSON 信息传输起来，体积很大，如果项目里面文件夹层级复杂，可能会更大。

然后这个 JSON 后端是不感知的，从后端去对文件树做操作是很难的。当然后端也可以去 parse 这个 JSON 然后操作，但这样太麻烦了。

文件树在 DB 里面的存储其实很简单，存一个父节点指针，然后标识一下 level（层级）即可。在业务中查询的时候，我们一般就是查某个父节点下面的子节点列表，所以不涉及非常复杂的 DB 查询，只是一个简单的 Select。之前以为会很复杂，就想存在前端。

现在其实也可以做迁移。对每个项目，跑一个迁移脚本。把 JSON 拿出来，然后 parse，对里面的每个文件夹/文件/文档/文档夹做操作，就是在表里面加三个字段，一个是 parentId，用来定位父节点，一个是 level，用来标识层级（这个字段其实只需要最顶级的节点有标识就行，其他层级有没有无所谓），最后一个是一个排序的 sortIndex，一个父节点查到子节点列表后，就可以用这个 index 来做排序。这样就可以允许用户去调换节点的顺序。