前端和后端的思考
# 后端
最近使用 midwayjs 开发了一个后端的项目。这里记录一下遇到的问题。
# 中间件
可以处理用户鉴权，以及修改 request，返回固定格式的 response。
# 过滤器
主要是统一处理异常，因为公司是通过标准输出来收集异常日志，所以并不需要专门的 logger。可以直接使用console.log。
当然还可以使用 sentry 的 api 主动上报日志。
# 批量处理
通常如果是执行一个任务，我们可以直接返回任务执行是成功了，还是失败了。但是如果该接口是批量执行一批任务，那么就会涉及到有些任务执行成功，有些任务执行失败。主要是此时接口状态只能是成功，然后返回数据中包含两个数组。
{
"errCode": 0,
"data": {
"successResult": [],
"failedResult": []
}
}
2
3
4
5
6
7
# 服务
服务可以相互注入，但是最终会得到一个网状的依赖关系。更关键的是，因为任意一个服务都能访问到其他服务，导致有些逻辑代码不知道写在哪里合适，或者说写到哪里都合适。
建议把服务分成两种类型。
基础类型服务：此时的服务没有依赖其他服务，只能操作自己的数据和操作数据库。 业务类型服务：此时的服务依赖多个基础类型服务。可以实现复杂的业务逻辑。
控制器：其实本来控制器应该承担业务类型服务的角色，但是我发现，在控制器里面出现大量的具体的业务逻辑非常不利于维护和复用。控制器中只适用于逻辑路由和数据校验。
逻辑路由：应该在控制器中做具体的逻辑路由。
if (flag1) {
return doSomething1();
} else if (flag2) {
return doSomething2();
} else {
return doSomething3();
}
2
3
4
5
6
7
逻辑组合：应该在业务类型的服务中实现具体的业务逻辑。
doSomething1();
doSomething2();
doSomething3();
2
3
# 前端
前端最重要的就是快速实现 monorepo 来管理代码。当然也不是全部都要 monorepo，关键还是看场景。
比如类似 antd 和 element-ui 这样的统一 UI 库，实际上并不是 monorepo，这是因为这些组件是统一发版的。当然也可以采用 monorepo 来管理。
如果是公司内部的组件库，最好还是每个组件单独发版，这种场景比较合适 monorepo。
像赛事系统还有模块化系统这种复杂的多项目系统，最好也是采用 monorepo 来维护，因为这样可以在不同项目之间共享一些代码。