随笔分类

随笔档案

阅读排行榜

推荐排行榜

十六、编辑器服务端基础API开发

1、技术方案设计和基本功能开发

* 引言
    - 需求指导设计，设计指导开发。无设计不开发。
* 标题
    - 服务端技术方案设计 & 基础功能开发
* 将收获什么
    - 服务端技术方案设计的方法
    - B端和编辑器基本功能API
* 主要内容
    - 技术方案设计
    - 基本功能开发
* 关键词
    - 技术方案设计文档（架构设计、接口设计、数据库设计）
* 学习方法
    - 亲自写出来，无论是代码还是文档
* 注意事项
    - 业务代码不会一行一行写
    - 回顾一下之前的“整体架构设计”，各个项目之间的关系，以及和数据库之间的关系。

2、技术方案设计

* 引言
    - 领导技术方案设计、评审技术方案设计，这就是架构师和基层程序员的区别之一。
* 主要产出
    - 《biz-editor-server端技术方案》文档
* 主要内容
    - 接口设计
    - 选择Restful API，不是GraphQL
    - 数据库设计
    - server整体设计
* 注意事项
    - 正视技术方案设计，设计不会浪费时间，只会节约时间
    - GraphQL不是课程主线，不要跑偏

3、接口设计

* 引言
    - 把server端当做一个黑盒，它将怎样与前端通讯？
* 功能范围
    - B端，用户注册，作品管理，模板
    - 编辑器，单个作品的内容获取、修改、预览和发布
* 功能拆分
    - 用户信息
    - 作品管理
    - 模板
    - 编辑器（发布和渠道，可以单独设计）
    - 工具类
* 用户信息
    - 获取手机短信验证码
    - 登录（包含注册）
    - 获取用户信息
    - 修改用户信息
* 模板
    - 首页推荐模板列表（搜索，分页）--不需要登录校验
    - 获取单个模板信息--不需要登录校验
    - 我的模板列表（搜索，分页）
* 作品管理
    - 创建空白作品
    - 复制作品（通过模板创建）PS：模板即作品，只是有一个标志而已，数据库设计时可以看出来
    - 删除作品
    - 恢复作品
    - 转赠作品
    - 我的作品列表（搜索，分页）
    - 我的回收站列表（搜索，分页）
* 编辑器
    - 设计时分开，但代码中可能会和作品管理写在一起，因为都是针对作品的。
        ~ 查询单个作品信息
        ~ 保存作品
        ~ 预览作品
        ~ 发布作品
        ~ 发布为模板
* 渠道
    - 创建渠道
    - 删除渠道
    - 修改渠道名称
    - 获取单个作品的所有渠道
* 工具类
    - 上传图片
* 统一的输出格式
########
{
    errno: 0, // 错误码，无错误则返回0
    data: {...}, // 或者[...]
    message: 'xxx'
}
########
    - 留作业，设计每个接口的输入和输出，可使用第三方工具YAPI。
* 其他
    - 作品统计，会用到单独的统计服务，不在这里出数据
    - 预览作品，在h5-server中
* 小结
    - 功能拆分
    - 详细的接口设计
    - 统一输出格式

4、Restful API vs GraphQL

* 引言
    - 默认所有同学都已非常熟悉Restful API。而GraphQL大家可能比较陌生，会放慢节奏。
    - 而GraphQL是和Restful API完全不同的两种设计和实现方式，
      两者也尽量不要混用（虽然混用也能做到无bug）
* 什么是GraphQL
    - GraphQL-Graph Query Language图查询语言。意思是擅长处理“图”数据结构的查询，
      即多个数据对象，各个之间还有关联关系。
    - 核心概念：
        ~ schema - 数据规范
        ~ rootValue - 数据源
    - 代码演示，可参考中文官网。注意，在此不要深入进去，还是沿着课程主线走。
########
var express = require('express');
var graphqlHTTP = require('express-graphql');
var { buildSchema } = require('graphql');

// 使用GraphQL Schema Language创建一个schema
var schema = buildSchema(`
  type Query {
    hello: String,
  }
`)

// root提供所有API入口端点相应的解析器函数
var rootValue = {
  hello: () => {
    return 'Hello world';
  },
};

var app = express();
app.use('/graphql', graphqlHTTP({
  schema: schema,
  rootValue: rootValue,
  graphiql: true,
}));
app.listen(4000);
console.log('Running a GraphQL API server at http://localhost:4000/graphql');
########
    - 另外，虽然GraphQL主要用于查询，但它也支持输入和更新，参考官网input和Mutation。
      课程就不在继续扩展了。
* GraphQL的应用场景
    - 数据关系比较复杂。PS：和我们正好相反，我们是作品的数据结构复杂（前端编辑器复杂），
      而数据实体之间的关系比较清晰。
    - 前端查询需求多变，如果用Restful API会导致频繁地修改API，不灵活。
    - 有一个独立的数据提供方，对接很多使用方，不能一一定制开发
* 如何选择
    - 选择使用Restful API，放弃GraphQL。
    - 并不匹配它的使用场景
    - 考虑它的缺点：
        ~ 学习使用成本高，不如Restful API普及
        ~ 当数据结构复杂时，效率较低
        ~ 维护数据源和schema也比较复杂
* 小结
    - GraphQL介绍
    - 应用场景
    - 选择Restful API

5、数据库设计

* 需要存储的数据
    - 用户
    - 项目/模板（包含项目内容，组件信息）
    - 渠道
* 数据之间的关系
* 数据表设计
    - 注意，使用sequelize和mongoose，会自动创建id、createdAt和updatedAt，无需再自己手动创建。
* 用户
* 作品/模板
* 渠道
* 作品内容
    - 未发布
    - 发布
########
{
    // 页面的组件列表
    components: [Object],
    // 页面的属性，如页面背景图片
    props: Object,
    // 配置信息，如微信分享配置
    setting: Object,
}
########
* 代码演示
    - sequelize Model以及关联关系
    - mongoose Schema和Model
* 小结
    - 数据表设计
    - 数据表的关系
    - 代码演示

列	类型	注释
username	varchar	用户名，唯一
password	varchar	密码，保留字段，暂时用不到
phoneNumber	varchar	手机号
nickName	varchar	昵称
gender	int	性别（1男性，2女性，0保密）
picture	varchar	用户头像
latestLoginAt	date	最后登录时间
isFrozen	boolean	用户是否冻结

列	类型	注释
uuid	varchar	uuid，h5 url中使用，隐藏真正的id，避免被爬
title	varchar	标题
desc	varchar	副标题
contentId	varchar	未发布内容id，内容存储在mongodb中
publishContentId	varchar	发布内容id，内容存储在mongodb中，未发布的为空
author	varchar	作者username，和用户表关联
coverImg	varchar	封面图片url
isTemplate	boolean	是否模板
status	int	状态：0-删除，1-未发布，2-发布，3-强制下线
copiedCount	int	模板被使用的次数
lastestPublishAt	date	最近一次发布的时间
isHot	boolean	hot标签，模板使用
isNew	boolean	new标签，模板使用
orderIndex	int	排序参数
isPublic	boolean	模板是否公开显示

列	类型	注释
name	varchar	渠道名称
workId	int	作品id
status	int	状态：0-删除，1-正常

6、server架构设计

* 引言
    - 回顾egg.js的代码结构。
* 整体架构图
* 写文档
    - 在语雀中新建文档《biz-editor-server端技术方案》，目录
        ~ 范围（以及和其他项目的关系）
        ~ 技术选型
        ~ 整体架构设计
        ~ 接口设计
        ~ 数据库设计
* 小结
    - 架构设计图
    - 写文档

7、技术方案设计

* 引言
    - 领导技术方案设计、评审技术方案设计，这就是架构师和基层程序员的区别之一。
* 主要产出
    - 《biz-editor-server端技术方案》文档
* 主要内容
    - 接口设计
    - 选择Restful API，不是GraphQL
    - 数据库设计
    - server整体设计
* 注意事项
    - 正视技术方案设计，设计不会浪费时间，只会节约时间
    - GraphQL不是课程主线，不要跑偏

8、基本功能开发

* 主要产出
    - 基础功能的接口，并发布到测试机
* 主要内容
    - 登录功能
    - 用户信息接口
    - 作品接口
    - 模板接口
* 注意事项
    - 发布相关的接口和渠道接口，会在下一周讲解
    - 发送短信功能还没有，先模拟
    - 简单的代码不在从0手写
    - 注意规范的研发流程，如git分支规范、commit规范、合并代码等

9、登录功能

* 引言
    - 回顾JWT的登录校验过程
* 短信验证过程
* 初次获取验证码
    - request - 输入手机号，请求短信验证码
    - server - 生成4位随机数，缓存2min
    - res
        ~ 发短信验证码
        ~ 返回给前端{ errno: 0 }
* 再次获取验证码
    - request - 输入手机号，请求短信验证码
    - server - 检查缓存，无则生成，并再次缓存
    - res
        ~ 有缓存，则返回错误：不能频繁获取
        ~ 发送短信验证码，并返回给前端{ errno: 0 }
* 登录验证
    - request - 书记好、验证码，请求登录验证
    - server - 匹配缓存
    - res
        ~ 匹配成功，则验证通过
        ~ 匹配失败，则验证不通过
* 重点考虑
    - 费用
        ~ 缓存，禁止频繁发送
        ~ 短信服务的提示和报警（后面会讲）
    - 用户体验
        ~ 短信发送失败，不会缓存，可以立马重新生成验证码
    - 稳定性
        ~ 如果server缓存失败，那就允许用户重复调用。情况较少，没关系
        ~ 短信服务挂掉，报警（后面会讲）
    - 注意事项
        ~ 发送短信，暂时模拟
        ~ 可以写个文档，虽然已经经过了技术方案设计，但有些写在开发前如果感觉复杂，
          可以写个设计文档再评审一下。及时发现问题，及时沟通。
* 小结
    - 短信验证过程
        ~ 生成验证码
        ~ 验证
    - 重点关注

10、用户信息接口

* 研发过程
    - 研发规范的细节，会在课程最后总结，先实践起来。
        ~ 拉新分支feature-xxx fix-xxx hotfix-xxx
        ~ 修改代码
        ~ commit，参考.cz-config.js
        ~ 往dev分支提交pr Pull Request（gitlal中是mr Merge Request）
        ~ 代码走查
        ~ 合并代码到dev
        ~ 等待发布上线
* 接口
    - 获取手机短信验证码
    - 登录（包含注册）
    - 获取用户信息
    - 修改用户信息
* 代码演示
    - routes/users.js
    - controller/users/
    - service/users.js
    - cache/users/
    - __test__/apis/users.js接口测试
* 测试
    - npm run test:local
    - 使用postman手动测试
* 小结
    - 注意研发过程
    - 接口
    - 代码演示
    - 测试

11、作品管理接口

* 接口
    - 创建空白作品
    - 复制作品（通过模板创建）
    - 删除作品
    - 恢复作品
    - 转赠作品
    - 我的作品列表（搜索，分页）
    - 我的回收站列表（搜索，分页）
    - 查询单个作品信息
    - 保存作品
* 代码演示
    - routes/works.js
    - controller/works/
    - service/works.js
    - __test__/apis/works.js
    - PS：发布相关的，下周再讲解
* 测试
    - npm run test:local
    - 使用postman手动测试
* 小结
    - 接口
    - 代码演示
    - 测试

12、模板接口

* 接口
    - 首页推荐模板列表（搜索，分页）--不需要登录校验
    - 获取单个模板信息--不需要登录校验
    - 我的模板列表（搜索，分页）
* 代码演示
    - routes/templates.js
    - controller/works/findTemplate
    - cache/works/templates
    - __test__/apis/template.js
* 测试
    - npm run test:local
    - 使用postman手动测试
* 小结
    - 接口
    - 代码演示
    - 测试

十七、编辑器服务端调用第三方服务

1、重要功能 & 第三方服务

* 引言
    - 根据2/8原则，关键的一小部分功能，将花费大部分设计和开发成本。
* 将收获什么
    - 完整的发布功能（考虑线上业务闭环）
    - 新技术/第三方服务调研（初次使用的，并非新发明的）
* 主要内容
    - 发布相关的功能
    - 接入短信服务
    - 上传图片到阿里云oss
    - 内容安全检查
* 关键词
    - 第三方服务
    - 新技术调研
* 学习方法
    - 自己去申请第三方服务，一般可试用或费用很低
    - 第一次使用一个新技术，要写一个单独的demo去体验一下，别直接拿到项目中
* 注意事项
    - 业务代码不会一行一行写
    - 课程中会隐藏第三方服务的秘钥，请理解
    - 第三方服务的价格、控制台、文档、API都可能会有调整
    - 特别是内容安全检查，可能会频繁调整（制作课程期间，就遇到了一次调整）

2、发布相关的功能

* 引言
    - 发布，是一个作品的生命周期里，最重要的一个环节。有很多事情需要考虑。
* 主要产出
    - 完成发布功能相关的接口
* 主要内容
    - 发布功能的设计
    - 如何强制下线？
    - 功能开发
* 注意事项
    - 考虑业务闭环，如重新发布时链接不能变
    - 分渠道的重要性！

3、发布功能的设计

* 引言
    - 发布，即获取一个url，能外网访问该作品。
* 功能范围
    - 发布作品
    - 支持多渠道
    - 发布为模板
* 划重点
    - url不能太长，因为要生成二维码。
    - 作品发布之后，重新编辑，保存，未发布。此时不能在线上生效。
    - 再次发布时，url不能变，渠道号也不能变。
    - 用户访问url时必须带有渠道号，否则无法分渠道统计。
    - 注意数据保密，防爬。
    - 发布时进行内容安全检查--本周后续的课程会讲。
    - PS：此时也能体现出，真实线上业务和demo是不一样的，业务闭环。
* 发布作品
    - 回顾：多个项目公用一个数据库。
* url
    - 发布作品，就是拼接一个url，其中有作品的id。可让h5-server访问该作品数据，并渲染出页面。
    - 例如http:127.0.0.1:3002/p/100，其中p发布作品（预览时可以改为preview），100是作品id。
* 标记
    - 未发布的作品，不能通过该url访问到。因此发布的作品要加一个标志。
    - 数据库设计，作品数据表status“0-删除，1-未发布，2-发布，3-强制下线”
* url加uuid
    - 还要防爬，所以要加上uuid，如http:127.0.0.1:3002/p/100-xxx。
    - 所以，这就是为何在设计数据表时要增加一个uuid。
    - 这就要求h5-server，必须同时匹配id uuid status。如有一条不满足，则返回404。
* 重新修改作品
    - 作品发布了，重新编辑，重新保存，尚未重新发布。
    - 此时访问作品，应该是原来发布的内容。
    - 所以，mongodb中作品内容和发布内容，要分开。
    - 参考数据库设计时的关系图。
* 多渠道
    - 回顾：多渠道统计需求，对于运营人员的重要性。
    - 渠道就是一个url参数，如http:127.0.0.1:3002/p/100-xxx?channel=1。
    - 一个作品可以对应对应多个渠道，至少要有一个渠道。回顾数据库设计时的关系。
    - 从技术角度，一个作品就是一个资源实体一个url，渠道仅仅是一个参数。
    - 但从用户使用角度，一个作品就可以发布出多个页面，多个二维码。
    - PS：直接访问一个无渠道的作品，也是可以的，但不建议这样做，h5-server应该做限制。
* 发布为模板
    - 模板就是作品，一个标记isTemplate而已。使用模板创建，其实就是复制。
    - 发布模板也是拼接一个url http:127.0.0.1:3002/p/100-xxx，然后修改status。
    - 但是，模板没有渠道，也不需要渠道。
* 小结
    - 发布为作品，以及重新修改
    - 多渠道
    - 发布为模板
    - PS：发布功能，是biz-editor-server和h5-server的共同功能，所以要两者都要考虑。

4、如何强制下线

* 引言
    - 这是一个必要的需求，用于人工保障内容安全，后台管理的重要功能。
    - 这个功能也影响了设计方案，原本是想要将作品发布到CDN上的。
* 发布项目到CDN
    - 直接将组件内容渲染成一个html，然后上传到oss，然后绑定CDN，可自定义域名。
    - 优点：
        ~ 不用专门搭建h5-server
        ~ CDN访问速度快（比现在h5-server的SSR速度还要快）
        ~ 不用担心“重新编辑，但未发布”的情况
    - 缺点
        ~ 后端渲染并发布CDN，导致biz-editor-server逻辑过于复杂（或者单独弄一个服务，
          渲染页面，上传CND）
        ~ 无法紧急下线
        ~ CDN一般用于存储静态资源，做强缓存，只增不减
        ~ 如果强行对一个资源做替换，不符合CDN的使用习惯，“反习惯”不可取
    - 结论，因为无法紧急下线，弃用CDN的发布方式。
* 紧急下线
    - 采用当前h5-server的方式。作品加一个标记status，即可实现紧急下线。
    - PS：h5-server不会每次都访问数据库，也是有缓存机智的，这个到时候再说。
* 小结
    - 发布项目到CDN
    - 紧急下线
    - PS：CDN还会用于其他地方

5、功能开发

* 引言
    - 功能要点搞明白，写代码就简单了。
* 发布作品和模板
    - routes/works.js发布相关的路由
    - controller/works/publishWorks.js
    - service/works.js发布功能
    - cache/works/publish.js
    - __test__/apis/works.js发布功能
* 渠道接口
    - routes/channel.js
    - controller/channel/
    - service/channel.js
    - __test__/apis/channel.js
* 测试
    - 接口测试
    - postman测试
* 小结
    - 发布作品和模板
    - 渠道接口
    - PS：预览功能，在h5-server开发，到时再讲。

6、发布相关的功能

* 引言
    - 发布，是一个作品的生命周期里，最重要的一个环节。有很多事情需要考虑。
* 主要产出
    - 完成发布功能相关的接口
* 主要内容
    - 发布功能的设计
    - 如何强制下线？
    - 功能开发
* 注意事项
    - 考虑业务闭环，如重新发布时链接不能变
    - 分渠道的重要性！

7、短信服务

* 引言
    - 真实项目项目，考虑用户体验。
* 主要产出
    - 《短信服务调研》文档
    - 登录验证码对接短信服务
* 主要内容
    - 短信服务调研
    - 配置短信服务
    - 实验demo
    - 代码演示
* 注意事项
    - 开通短信服务很容易，但使用短信服务需要审核（如需要域名备案的截图信息）
    - 课程中用到的手机号都是临时的。学习时，可以改用你自己的手机号。

8、短信服务调研

* 调研新技术方案的一般步骤
    - 列出所有竟品，根据品牌、功能、价格，选择一个最合适的
    - 购买或试用服务
    - 查阅文档和配置
    - 要单独写一个demo，体验一下
* 竟品对比
    - 已写到语雀文档中
        ~ 七牛云
        ~ 阿里云
        ~ 网易云
        ~ 腾讯云
    - 最后因为品牌、价格的原因，选择了腾讯云。
* 购买服务
    - 学习用，买最便宜的即可，少买。关注等待营销活动。
* 小结
    - 调研步骤
    - 竟品对比
    - 购买服务

9、配置短信服务

* 引言
    - 登录控制台：https://console.cloud.tencent.com/smsv2
* 基本配置
    - 创建签名
    - 创建模板
    - 群发测试
    - 配置成功后注意下面几个地方
    - appId-应用管理，应用列表
    - 签名的ID和名称-国内短信，签名管理
    - 模板ID和内容-国内短信，正文模板管理
* 安全配置
    - 防刷接口，导致短信调用量过大。
* 小结
    - 基本配置
    - 安全配置

10、实验demo

* 引言
    - 参考文档：https://cloud.tencent.com/document/product/382/43197
* 获取密钥
    - 右上角个人名称-->访问管理-->左侧菜单“访问密钥”：https://console.cloud.tencent.com/cam/capi
* demo
    - 先不要直接用于项目，先做一个单独的demo体验一下用法。
    - 抛开复杂的项目环境，才能获得最真实的体验。
    - 代码演示，注意判断发送是否成功。
* SDK升级
    - 在课程制作过程中tencentcloud-sdk-nodejs就升级过。导致安装了最新版本，之前的代码运行报错。
    - 而且，SDK升级了，但腾讯云的文档并没有更新，npm上的文档更新了。
    - 但是，目前npm文档还不全，没有写如何发短信。所以对于这种情况，我们没法使用最新版，还是依然使用之前的v3.0.263版本。
    - 待文档都更新了，再切换到新版本。
* 小结
    - 获取密钥（注意保密）
    - demo
    - 注意升级

11、功能开发

* 代码修改
    - vendor/sendMsg.js
    - controller/users/sendVeriCode.js（看相关代码，不用做演示）
    - __test__/vendor.test.js
* 测试
    - 单元测试
    - postman测试
* 小结
    - 代码修改
    - 测试

12、上传图片到阿里云OSS

* 引言
    - 文件存储交给OSS，我们只做server的业务逻辑。
* 主要产出
    - 开发上传接口
* 主要内容
    - 配置阿里云OSS
    - 实验demo
    - 代码演示
* 注意事项
    - 阿里云OSS要配置CDN，Sam老师会讲

13、配置阿里云OSS

* 引言
    - 文件存储使用阿里云OSS这是业界的最常见选择，不用再做技术调研。
    - PS：我还用过腾讯云的COS，不过配置操作和使用细节，跟阿里云OSS肯定不一样。作为参考吧。
* 购买
* 寻找折扣套餐
    - 此时OSS首页有一个折扣活动，非常便宜。
    - PS：折扣活动是有期限的，仅做为参考。
* 按量付费
    - 学习用，按量付费也很便宜。例如此时的几种价格，仅作为参考。具体的自己去官网看。
* 配置OSS
    - 购买之后，登录进入控制台
        ~ 创建Bucket。Bucket就像是你电脑里的硬盘。文档是以Bucket为单位来管理和存储的，可以创建多个Bucket。
        ~ 外网访问权限：公共读
* 小结
    - 购买
    - 配置
    - PS：配置CDN和自定义域名，Sam老师会讲解

14、实验demo

* 引言
    - 文档：https:/help.aliyun.com/document_detail/32068.html?spm=a2c4g.11186623.6.1382.42de2cc69fJBTZ
* 获取密钥
* demo
    - put
    - putStream
    - 存储到某个文件夹
    - isExist
    - 其他API，可以继续查阅文档。
* 小结
    - 获取密钥
    - demo
    - PS：参考你当前的文档，SDK和接口都可能发生变化。

15、代码演示

* 实现思路
    - 上传文件到服务器
    - 服务器上传到OSS
* 代码修改
    - routes/utils.js
    - controller/utils/uploadImg.js
    - vendor/uploadOSS.js
    - __test__/vendor.test.js OSS部分
    - PS：config线上环境和测试环境，两个bucket
* 测试
    - 单元测试
    - postman测试（需发布到测试机）
* 小结
    - 实现思路
    - 代码修改
    - 测试

16、内容安全检查

* 引言
    - 真实线上服务，内容安全非常重要，要能识别出：黄色、暴力、敏感内容。
* 主要产出
    - 《内容审查服务调研》调研
    - 发布作品接入内容安全检查
* 主要内容
    - 内容审查服务调研
    - 实验demo
    - 代码演示
* 注意事项
    - 内容安全检查，可能会随时调整
    - 偏重用户体验，还是偏重内容安全，自己抉择

17、内容审核服务调研

* 引言
    - 内容安全审查，不像OSS存储那样用的那么频繁，了解的不多，所以需要调研一下。
* 为何需要第三方服务
    - 内容审核为何非得用第三方服务？自己做一个敏感词检查不行吗？
    - 答案是：不合适，因为成本太高了。
        ~ 需要维护和更新词库
        ~ 自己用简单的indexOf做判断，时间复杂度太高了。如果词库长度m字符串长度n，那么时间复杂度
          就是O(m * (m + n)) （KMP算法时间复杂度是O(m + n)）
        ~ 需要判断作弊行为，如敏感词之间加空格
        ~ 扩展性：审核图片、音频、小视频等
* 调研
    - 参考语雀文档。
        ~ 百度云
        ~ 网易云盾
* 创建应用
* 小结
    - 原因
    - 调研
    - 创建应用

18、实验demo

* 引言
    - 参考文档：https://ai.baidu.com/ai-doc/ANTIPORN/Lk3h6xev0
    - 审核数据数据类型
        ~ 文本
        ~ 图片
    - PS：某些不合规的、敏感内容，我们就不演示了，希望理解。但返回结果我会讲清楚。
* 审核文本
* 内容合规
    - { conclusion: '合规', conclusionType: 1, log_id: 159920000460984 }
* 内容不合规
    - 特别注意，有些内容返回words而有些words为空。
    - 为此，我专门咨询过百度云的技术人员，得到的答案是“未命中他们的词库”，但我觉得不是这个原因。
########
{
    conclusion: '不合规',
    conclusionType: 2,
    log_id: 159920000460984,
    data: [
        {
            msg: '存在政治敏感不合规',
            conclusion: '不合规',
            hits: [
                {
                    datasetName: '百度默认黑词库',
                    words: ['xxx', 'yyy']
                }
            ],
            subType: 3,
            conclusionType: 2,
            type: 12
        }
    ]
}
########
* 审核图片
* 图片合规
    - { conclusionType: 1, conclusion: '合规', log_id: 159920000682630 }
* 图片不合规
    - 注意，有些不合规的就没有stars，如血腥图片。
    - 我觉得这是合理的，血腥图片没有特别的关键字，也不好头像识别。
########
{
    conclusionType: 2,
    conclusion: '不合规',
    log_id: 159920000682630,
    data: [
        {
            msg: '存在政治敏感不合规',
            conclusion: '不合规',
            subType: 0,
            conclusionType: 2,
            type: 5,
            
            // 有些不合规的就没有stars，如血腥图片
            stars: [
                {
                    "probability": 0.94308,
                    "name": "xxx"
                },
                {
                    "probability": 0.44308,
                    "name": "yyy"
                }
            ],
        }
    ]
}
########
* 如何判断审核失败？
    - 你有两种选择，但选择了，就要负责。所以要认真考虑。
* 以用户体验为主
    - 提示内容审核失败时，一定要提示关键字，哪里失败了。
    - 这样用户就能快速修改，再次发起审核。
    - 但是，有些审核失败是没有关键字提示的。
* 以内容安全为主
    - 不管有没有关键字，只看审核结果。
    - 但这样用户有时候很迷茫，只知道什么失败，但不知道失败在哪里，只能猜测、重拾。
    - 掘进博客的内容审核，就不提示关键字。
* 小结
    - 审核文本
    - 审核图片
    - 如何判断审核失败？
    - PS：一切以你当前的文档为主，文档可能就有调整

19、代码演示

* 引言
    - 线上环境，作品发布时，才出发内容审核，其他时候不需要。
* 代码修改
    - vendor/contentSensor.js
    - controller/works/publishWorks.js接入内容审核
    - __test__/vendor.test.js内容审核部分
* 测试
    - 单元测试
    - postman测试
* 小结
    - 代码修改
    - 测试

posted on 2023-10-13 14:27 一路繁花似锦绣前程阅读(31) 评论(0) 编辑收藏举报

刷新页面返回顶部

登录后才能查看或发表评论，立即登录或者逛逛博客园首页

相关博文：

· 第十二章、web前端架构师

· 第十章、web前端架构师

· 海报编辑器开发

· 前端技术-总结列表

· 2024年Web前端开发流程和学习路线（详尽版）

导航

搜索

常用链接

随笔分类

随笔档案

阅读排行榜

推荐排行榜

十六、编辑器服务端基础API开发

1、技术方案设计和基本功能开发

2、技术方案设计

3、接口设计

4、Restful API vs GraphQL

5、数据库设计

6、server架构设计

7、技术方案设计

8、基本功能开发

9、登录功能

10、用户信息接口

11、作品管理接口

12、模板接口

十七、编辑器服务端调用第三方服务

1、重要功能 & 第三方服务

2、发布相关的功能

3、发布功能的设计

4、如何强制下线

5、功能开发

6、发布相关的功能

7、短信服务

8、短信服务调研

9、配置短信服务

10、实验demo

11、功能开发

12、上传图片到阿里云OSS

13、配置阿里云OSS

14、实验demo

15、代码演示

16、内容安全检查

17、内容审核服务调研

18、实验demo

19、代码演示