前面一篇文章,我分别从NodeJS框架选型、数据库选型、登录校验和单元测试、接口测试几个方面阐述了我们服务端选型的依据。本篇文章我会详细的为大家介绍服务端整体架构设计以及不同模块之间的关联关系。
在专栏的第一篇文章,我用这张图作为整体架构图为大家做了开篇介绍。这里同样复用这张图来展开说明:

依赖服务端的有三部分:
- 编辑器(登录、活动、上传等工具类)
- 组件平台(组件列表、组件信息、组件新增、版本维护等)
- C端
编辑器服务端设计
首先是编辑器部分,也是整个系统的核心操作区。这部分主要涉及到用户的注册、登录,活动的创建、修改、预览和发布,图片、视频素材的上传等。

基本上划分为三部分:
- 用户信息
- 活动管理
- 工具类
整体代码设计也是标准的Restful API
风格:从route
开始,经过middleware
对入参做前置校验,然后经由controller
调度,最终由service
与数据库做交互(一般都是通过ORM
框架来做)
细分一下大致的接口: 用户信息相关
- 登录(和注册公用一个)post /users/login
- 获取用户信息 get /users/getUserInfo
- 修改用户信息 patch /users/updateUserInfo
活动相关
- 创建活动 post /activity/
- 复制活动 post /activity/copy/:id
- 查询单个活动信息 get /activity/:id
- 修改活动 patch /activity/:id
- 删除活动 delete /activity/:id
- 发布活动 post /activity/publish/:id
- 获取所有活动 get /activity/list
工具类
- 上传图片 post /utils/uploadImg
- 上传视频 post /utils/uploadVideo
了解了大概的接口,下面我们来着重看一下用户和活动的数据表设计。
数据表设计
数据表的设计在大型项目中是非常重要并且是很有意义的,提前确定字段的类型、含义以及表与表之间的关联关系。
在专栏的前几篇文章中,我们不止一次的提过:MySQL
是一个关系型数据库
,是一种结构化的数据存储形式,适合存储活动信息和用户信息;MongoDB
是一个非关系型数据库,适合存储文档类(一般是JSON)数据,这里对应就是活动内容对应的JSON数据。
用户
用户表相对比较简单,主要包含了用户名、密码、手机号、性别、用户头像:
列 | 类型 | 备注 |
---|---|---|
username | varchar | 用户名,唯一 |
password | varchar | 密码 |
phoneNumber | varchar | 手机号 |
gender | int | 性别(1 男性, 2 女性, 0 保密) |
avatar | varchar | 用户头像 |
const seq = require("../db/seq/seq");
const { STRING, DATE, BOOLEAN } = require("../db/seq/types");
const User = seq.define("user", {username: {type: STRING,allowNull: false,unique: "username",comment: "用户名",},password: {type: STRING,allowNull: false,comment: "密码",},phoneNumber: {type: STRING,allowNull: false,unique: "phoneNumber",comment: "手机号",},gender: {type: STRING,allowNull: false,defaultValue: 0,comment: "性别(1 男性,2 女性,0 保密)",},avatar: {type: STRING,comment: "头像(图片地址)",}
});
module.exports = User;
活动
活动表主要包含了活动标题、活动描述、内容id(和mongodb关联)、作者、封面、活动状态、最近一次发布时间:
列 | 类型 | 备注 |
---|---|---|
title | varchar | 标题 |
desc | varchar | 描述 |
contentId | varchar | 内容id,内容存储在mongodb中 |
author | varchar | 作者 username,和用户表关联 |
coverImg | varchar | 封面图片u |