app.js 5.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110
  1. 'use strict';
  2. // 1.补充接口文档
  3. // 2.禅道问题
  4. // 3.数据导入
  5. // TODO 2020.03.12
  6. // TODO 图表速度慢,探访定位超范围问题
  7. // TODO 2020.03.02
  8. // TODO 探访表,添加老人类别,老年人能力状况,关爱服务需求 (探访各个地区,老人类别分布图)
  9. // 1.1 数据库备份,修改表结构,对已有数据进行批量修改
  10. // 1.2 修改探访添加逻辑,在添加探访数据时 添加老人类型
  11. // 1.3 修改采集信息的老人类型时,探访数据 ???
  12. // TODO 2.人脸比对 价格问题 按照5000次/天 1QPS/月/300元
  13. // TODO 3.项目安全问题
  14. // 0304
  15. // TODO 1.微信端推送消息 2.图片备份 3.老人二维码 4.探访员 工作总结报告
  16. // TODO 微信端 赡养人探访查询
  17. // TODO 积分表,添加dept1-5 (各个地区总积分,个人积分统计图)
  18. // TODO 采集数据导出问题,数据量大,只有县区及以下可以导出
  19. // TODO 3 当前model 存在ObjectId 的字段有:role dept + dept1-5 userid
  20. // TODO 涉及到的表:family:dept1-5 userid info:dept1-5 userid fid visit:dept1-5 userid fid
  21. // TODO user:dept1-5 role dept value:fid userid
  22. // TODO 4.涉及传到接口的参数格式没有校验 类型或者规则 有可能前端有规则但是接口没规则
  23. // TODO 参数检验,参数类型条件,参数个数,直接用query进入可能会导致一些字段权限过大,被修改
  24. // TODO 4.1 数据库如何做类型校验,防止除接口 外的数据修改异常
  25. // TODO 1微信用户权限问题 , 还有role相同页面下因为dept权限不同导致的问题?
  26. // TODO 权限问题通过 添加role 的api权限来控制一部分,验证当前登录人的role下是否有这个api 有就可以操作 无返回
  27. // TODO 5.身份权限:比如dept模块的增删改查 对于所有角色都是开放的,
  28. // 但是每个人根据部门的不同只有部分部门下的操作权限,
  29. // TODO 现在只做前端拦住这部分权限,但是接口还是可以进来
  30. // TODO 后台 服务层如何优雅的返回数据处理 微信端组件封装
  31. // TODO 1.角色管理添加菜单的下级api权限管理 -- 全新权限模块 --涉及到api层
  32. // 2.菜单管理考虑用属性ui重构,就不用分页了
  33. // 3.参考egg 和 vue框架处理一下前后端不好的地方 后端抛出异常方式
  34. // TODO 查询优化:(1)只要能做到单点登录 保证登录中redis存储的用户信息不改变,所有的用户数据就可以直接在
  35. // redis里面取 而不是拿出来再去请求user单个接口 可以在用户的表 里面再加一个字段记录sessionId
  36. // 当user发生编辑或者删除的时候 通过sessionId去查对应redis存在userjson不,存在就覆盖即可。
  37. // =======
  38. // 模拟sessionId,(采取来源ip 来源设备 渠道,是否代理,跨网页请求防止?)
  39. // 获取静态资源的权限 比如静态图片 静态页面 静态文件excel等
  40. // 页面权限和实际访问服务器内部的逻辑处理权限(即没有页面 走api也能跨权使用功能)
  41. // 后台所有接口都有可能存在 同步表操作的问题 比如info的update 比如session的存取修改等.暂时不考虑
  42. // oss图片功能替换,文档整理swagger接入,其他文档整理 导出表格 和 二维码下载深度考虑
  43. // 权限模块 细致(目前只有菜单权限,需要设计 添加点权限和后台api权限 )需要更改菜单模块
  44. //
  45. // 借鉴:1.路由不要全写,在获取用户的role的时候再添加到路由表
  46. // 2.子父数据树形 2.1把多级记录下来
  47. // 3.高级搜索 7.同步异步修改数据库问题 7.1excel 导出info
  48. // 4.批量删除? 5.thow exception 来返回客户端异常状态 全部异常处理
  49. // 6.后期审计的时候考虑 错误数据怎么处理 身份证重复数据怎么处理 配偶不在一户的怎么处理
  50. // 8前台代码健壮性问题:代码封装,一键调用等,Vue3改造
  51. // 9完善个人信息的事
  52. // 11.info整个逻辑分类和优化
  53. module.exports = app => {
  54. // 开始前执行
  55. app.beforeStart(async () => {
  56. await app.runSchedule('accessToken');
  57. });
  58. // 准备好执行
  59. app.ready(async () => {
  60. // 举例,获取数据库图片域名,放到缓存,便于使用
  61. });
  62. // 关闭前执行
  63. app.beforeClose(async () => {
  64. // this.app.logger 应用级别的日志记录,如记录启动阶段的一些数据信息,记录一些业务上与请求无关的信息
  65. // this.app.coreLogger 开发应用时都不应该通过 CoreLogger 打印日志,而框架和插件则需要通过它来打印应用级别的日志,这样可以更清晰的区分应用和框架打印的日志,通过 CoreLogger 打印的日志会放到和 Logger 不同的文件中
  66. // this.ctx.logger 请求相关的,它打印的日志都会在前面带上一些当前请求相关的信息(如 [$userId/$ip/$traceId/${cost}ms $method $url])
  67. // this.ctx.coreLogger 和 Context Logger 的区别是一般只有插件和框架会通过它来记录日志
  68. // Controller Logger & Service Logger this.logger 本质上就是一个 Context Logger,会额外的加上文件路径
  69. // 同时 Context 上也挂载了 Request 和 Response 两个对象。和 Express 类似,
  70. // 这两个对象都提供了大量的便捷方法辅助开发,例如
  71. //
  72. // get request.query
  73. // get request.hostname
  74. // set response.body
  75. // set response.status
  76. // 参数校验 validate接入egg
  77. // this.ctx.curl 相当于ajax
  78. });
  79. // 监听
  80. // app.once('server', server => {
  81. // // websocket
  82. // });
  83. // app.on('error', (err, ctx) => {
  84. // // report error
  85. // });
  86. // app.on('request', ctx => {
  87. // // log receive request
  88. // });
  89. // app.on('response', ctx => {
  90. // // ctx.starttime is set by framework
  91. // const used = Date.now() - ctx.starttime;
  92. // // log total cost
  93. // });
  94. };