38 篇博文 含有标签「Feathers.js」

发布时间：2024-05-06
作者：一介布衣
标签：Feathers.js, 快速上手, API开发, 实战教程

发布时间：2024-05-01
作者：一介布衣
标签：Feathers.js, 实时应用, Web框架, Node.js

后台系统一开始往往只有“管理员能不能进”这种粗粒度控制，但到 2021 年多数内部平台都已经会继续长出编辑、审核、运营、只读查看这类角色。权限体系复杂度一起来，最容易乱掉的就是概念边界。

做内容后台时，列表接口很容易越做越贪心：想把作者名、分类、标签、审核状态、最近操作人一次全带出来。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 顺序。认证、挂载用户、权限判断、审计记录，这些动作单独看都不复杂，连起来就很考验边界。

Feathers.js 用久了以后，params 会变成一个既好用又危险的对象。好用在于请求上下文、当前用户、provider、query 都能顺手带进 service；危险在于它太方便了，方便到什么都想往里放。