自动化机器人项目技术预研
一、预研概述
1、概述及背景
用户痛点：
（1）安服国内特性小组每周上线两次，拉封板和合入 master 的代码都是人工在群里通知的形式。
（2）国内不同的特性小组相对于 mater 尝尝有不同程度的落后，小则大几十次提交，多则上百，造成代码合入冲突，需要时间解决冲突，还有可能造成合入引发。
关键价值(期望)：
（1）仓库代码从某个分支合入某个分支能自动在 dim 进行通知。
（2）某些 pr 被合并的时候能自动在仓库创建 tag。
（3）收到某个分支的推送事件时能自动创建合并请求。
2、重构原因
目前的项目有着功能单一、不够健壮、工程化不全面的缺点，需要在保障功能的前提上进行重构，让项目更加健壮、代码更有质量。
3、功能目标
前期先开发服务端，用于处理合并事件、推送事件、评论事件等等。
中期会引入数据库，提升数据的稳定性。
后期会加入配置页面，用户进行可视化配置后存入数据库，事件触发时交给服务端去处理。
4、预研思路
主要针对以下 4 个方向进行预研
（1）服务端框架选型方案预研
（2）数据库选型方案预研
（3）ORM 框架选型方案预研
（4）包管理工具选型方案预研
（5）代码管理方式选型方案预研
二、预研方案说明
1、服务端框架选型方案预研
列举 koa 和 express 主要是为了对基于它俩封装的上层框架 Egg 与 NestJs 进行简单对比。
综合对比：NestJS 提供了更多的选择，更加自由以及更偏向后端开发的体验，而 Egg 作为深度定制过的框架，自定义的程度会弱于 NestJS。
Egg 更关注企业的维度，NestJS 更注重项目这个维度。
最终服务端框架选型方案：Nest.js
理由：
（1）相比 Egg，Nest 是原生使用 Typescript 实现的框架，所以原生支持 ts 类型。
（2）相比 Koa 和 Express，Nest 提供了一套完整的解决方案，包含了认证、数据库、路由、http 状态码、安全、配置、请求等开箱即用的技术。
（3）Nest 是基于 Express 实现的，需要的话可以取到底层的对象，如 request 和 response
（4）Nest 支持增量热更新，而不是全量更新
（5）大企业在用，大众开发者接受，生态不小，Bug 还少
2、数据库选型方案预研
数据库选型方案：Mysql
理由：
（1）历史悠久，社区及用户非常活跃，遇到问题，可以寻求帮助。
（2）软件体积小，安装使用简单，并且易于维护，安装及维护成本低。
（3）支持多种操作系统，提供多种 API 接口，支持多种开发语言。
（4）性能卓越，服务稳定，很少出现异常宕机。
（5）作为一个小项目，没有固定专门负责迭代和维护的开发团队，必须降低开发者的时间成本，mysql 相对于 mongodb 比较容易上手
MongoDB 数据处理方式 是基于内存的，将热数据存在物理内存中，从而达到高速读写。由于性能出色，一般用在博客、内管管理等大数据存储的系统中较为合适。而小项目没有复杂的权限设计和数据的频繁读写。
MongoDB 想要达到高可用需要设计高扩展性的集群架构，这对纯前端维护的项目意义不大，不如直接用 mysql。
3、ORM 框架选型方案预研
结论：Sequelize
ORM 框架选型方案：TypeORM
理由：
（1）Nest 出品，完美配合
（2）Ts 编写的最好的 ORM 框架
（3）简洁、功能强大、star 数更多、社区活跃
以下是拿的 sdsp 的 h5 的预研方案
4、包管理工具预研
结论：pnpm
5、代码管理方式预研
最终结论：Multirepo
7.10 的时候认为：选用 Monorepo，考虑到后期会接入前端页面，Multirepo 还要拆成两个仓库，所以选用 monorepo 比较合适。
7.11 的时候实践了一下，nestjs 自带的 monorepo 模式不是很好用，所有依赖都在根目录安装。但是在 nestjs 中使用 pnpm 改成 monorepo 的方式管理项目的话在装依赖的时候挺坑的。
请教了一些大佬以后发现对于前后端并没有什么可以公用的部分的这类项目，强行 monorepo 并没有什么意义，monorepo 的优势在于子应用单独管理依赖、单独部署，对于共用的依赖可以提升到根目录。
但是对于前端只有登录 + 配置页来说，没有需要复用的模块和依赖，前端部分属于短期维护几小时就能做完的独立的项目，最后的结论是拆成两个仓库。
Monorepo：使用一个 Git 仓库管理项目相关的多个 模块/包/功能/应用。（单一代码库）
Multirepo：又称为 polyrepo，使用多个 Git 仓库分别管理项目的每一个 模块/包/功能/应用。（多代码库）