57 篇博文 含有标签「Sequelize」

做内容后台时，列表接口很容易越做越贪心：想把作者名、分类、标签、审核状态、最近操作人一次全带出来。Sequelize 的 include 看上去正好可以满足这种愿望，但到了 2021 年，很多团队也已经踩出经验了，这条路要克制。

如果把 2021 年我最看重的 Node.js 后端关键词挑几个出来，Feathers.js 和 Sequelize 都会在里面。一个擅长把服务边界收清楚，一个擅长把关系型数据操作写得更稳，把这两个放在一起，其实很适合做轻量后台。

很多人喜欢 Feathers.js，往往就是因为 Hook 用起来很顺。但到了 2021 年，团队一旦把它大量用于后台服务，很快就会遇到一个副作用：before、after、error 三类 Hook 什么都能写，于是什么都开始往里面塞。

Feathers.js 之所以适合内部平台，一个重要原因就是 service 边界天生比较清楚。但真到项目做大以后，大家又会遇到另一个问题：一个后台模块到底应该由哪些文件拼起来，放在什么层级最稳？

后台开发里最常见的接口，就是列表页。可也正因为它太常见，团队很容易在 2021 年这种快速迭代环境里把它写成“每个模块各有一套参数”。等到前端页面一多，分页契约不统一的代价就会开始出现。

Feathers.js 到了 2021 年已经很适合做内部后台，但真正把它和 Sequelize 组合起来后，团队最容易踩坑的地方之一，就是 Hook 顺序。认证、挂载用户、权限判断、审计记录，这些动作单独看都不复杂，连起来就很考验边界。

刚开始用 Sequelize 的时候，模型定义很像一件机械活：写字段、配表名、导出模型，就结束了。可项目一大，模型之间开始出现 belongsTo、hasMany、belongsToMany 这类关联之后，我越来越觉得“模型怎么注册、谁先初始化”已经不是小事了。