pnpm add koa -S
app.use 是一个使用中间件的过程,接受一个函数作为参数
这里说的是后端路由,也就是不同URL,可以返回不同的内容。
ctx.url ===ctx.request.url
// 获取url信息
ctx.method ===ctx.request.method
// 获取请求类型
ctx.status===ctx.response.status
//设置返回的状态码
pnpm add koa-router -S
使用:
- 导入koa-router
- 创建router实例
- 注册
通过Router初始化
权限校验
自定义权限校验中间件
- 检测服务器所支持的请求方法
- cors中的预检请求
allowedMethods
作用:响应options方法
支持但方法不允许--405
不能识别该类型的方法--501
注意删除用户返回204即可8.
拿到路由分配的任务,并执行
在koa中控制器就是一个中间件
为什么需要控制器
- 获取http请求参数
- 处理业务逻辑
- 发送http响应
路由参数是必传的。而query是可选的
url长度有限制
解析请求体中的内容,如果没有这个中间件,请求就拿不到 ctx.request.body中的内容
pnpm add koa-bodyparser -S
const bodyParser = require('koa-bodyparser')
app.use(bodyParser())
设置响应头: ctx.set('content-Type','aplication/json')
路由中的每一个js文件代表了一个路由模块。通过自动化脚本实现对路由的注册
这个自动化脚本接受一个app实例作为参数。
constrollers 数据处理层
运行时错误,返回500
逻辑错误,如找不到( 404)、先决条件失败( 412 )、无法处理的实体(参数格式不对,422 )等
412 例如寻找的用户id不存在
pnpm add koa-json-error
use
根据当前环境切换 返回内容
pnpm add cross-env -D
配置error中的postFromat对象的返回参数
配置package.json 文件
pnpm add koa-parameter -S
通过verifyParams来限制请求体中的参数,如果不满足返回422
noSql
- 列存储
- 文档存储mongoDB---按照json来存储
- key-value存储 redis
why no sql
- 简单 (没有原子性、一致性、隔离性等复杂规范)
- 便于横向扩展
- 适合超大规模的存储
- 灵活存储复杂的数据 Schema Free
中文含义为 “庞大的” 面向文档
的开源数据库
- 性能好(内存计算)
- 大规模的数据存储(可扩展性)
- 可靠安全(本地复制,自动故障转移)
- 方便存储复杂的数据结构
下载 直接本地下载
云mongoDB ->更加安全,不需要自己去维护服务器
mongodb+srv://vujson:@zhhu.zbgci.mongodb.net/myFirstDatabase?retryWrites=true&w=majority
mongoose 操作mongoDB
安装: pnpm add mongoose -S
schema 相当于对json(表的定义)的数据约束
model定义文档,文档是模型的实例
- 编写用户模块schema -> 使用schema生成用户的modal
const mongoose = require('mongoose')
const { Schema, model } = mongoose
const userSchema = new Schema({
name: { type: "string", required: true }
})
module.exports = model('User', userSchema)
查询所有用户
find
寻找某个id的用户
findById
创建某个用户
new model().save()
删除某个id的用户
model.findByIdAndRemove()
更具id更新某个用户
model.findByIdAndUpdate()
优势
- 服务器可以主动清除sessionId。
- session存储在服务器,更加安全。
- 结合cookie使用,兼容性好。
- 只需要传输sessionId开销小。
劣势
- cookie+session在跨域的场景中表现不好 *
- 分布式部署的话,多机共享session。
- 基于cookie容易被csrf --
- 查询session有个数据库查询过程
定义了一种紧凑且独立的方式,跨域将各方之间的信息作为JSON对象进行存储。
该信息可以被验证和信任,因为是经过数字签名的。
缺点: 无法手动处理jwt,如果做一些权限的服务,必须等到token过期才会重新生效,修改完
jwt构成
- header
- 有效载荷(payload)
- 签名 signature
需要传递的信息: 用户ID、用户名等
包含过期时间、发布人等,payload可以进行加密
保证Token
hash256算法对已经进行base64处理后的header和payload进行加密
安装jsonwebtoken
pnpm add jsonwebtoken
jwt.decode(token) 对token进行解码,但是无法确保token是否被篡改
jwt.verify(token,'密钥')
secret : 设置密钥
jwt.sign() 签证: 第三个参数 expireIn:设置过期时长
添加到需要进行认证的路由上
对用户身份进行校验,token有效之后,需要确认token中的id和当前params中的id是否一致
pnpm add koa-jwt -S
- 基础:上传图片。生成图片链接
- 附加:限制大小和类型,生成高中低三种分辨率的链接,生成CDN
pnpm add koa-body
替换 koa-bodyparser 后者不支持文件格式
- 设置图片上传目录
v1
上传图片之后,服务器可以获取的参数列表
生成一个静态服务,指定一个文件夹,文件夹下的文件都可以通过http来进行访问
pnpm add koa-static -S
通过ctx.origin 设置服务源: 不能直接写死,dev / pro 地址不同
前端表单 限制图片格式类型上传文件
<form action="/upload" enctype="multipart/form-data" method="post">
<input type="file" name="file" accept="image/gif,image/jpeg,image/jpg,image/png,image/svg">
<button type="submit">提交</button>
</form>
koa-parameter verifyParams 参数
定义用户 following schema ref可以指定shema让其(id)相关联,后续可以通过populate指定
获取关注人列表
关注某个用户 : 携带token -> 关注者id
取消关注某个用户:
获取某个人的粉丝列表
- 1.校验 id格式是否正确 不满足ObjectId格式的抛出异常
- 2.校验用户的id是否存在,不存在的抛出404
topicsSchema设计
查找所有话题和 基于id查询某个特定的话题
自定义中间件判断id是否存在
创建话题和修改话题
- auth校验
- verifyParams 校验body参数
分页处理
模糊搜索 通过mongoose自带的 limit 限制 name 利用正则匹配query中的q字段
作用: 方便对数据的归类,例如可以收集所有相同职业的话题,还有公司话题等等
采用Schema.types.ObjectId 类型配合ref引用之后
进行用户查询的时候采用populate高级检索
更具query中的 fields来指定生成的字段 这里需要动态生成populater否则会全部返回
schema设计 ---在用户的schema中添加followTopic
users constroller 定义 关注和取消关注控制器
users constoller 关注话题列表
一个问题包含多个话题,图片信息,描述、关注问题。用户的问题列表
用户和问题的关系是一对多的关系,话题和问题是多对多的关系
questionSchema 设计
url: /questions/:questionsId/answers
answerSchema设计
后续curd基本一致这里不再记录
每次点赞的时候取消踩,点踩的时候取消赞
userSchema添加 collectionAnswers字段
UserCtl
user router
- 评论curd
- 问题-> 评论 用户->评论 一对多关系
- 一级评论和子级评论
三级嵌套接口设计
/questions/:qustionId/answers/:answerId/comments/:commentsId
CommentSchema设计
一级评论和二级评论
添加rootCommentID 跟评论的id replaceId 回复给哪个用户
添加日期功能