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

Feathers.js 的一个优点是接口很轻，find 方法配上 params.query 就能做出非常灵活的列表查询。但灵活也意味着风险，如果没有白名单，列表接口最后会变成“只要能拼出来就都能查”。

真正把 Feathers.js 用起来之后，很快会遇到一个问题: service 到底该写多厚，hook 到底该放多少逻辑？这个边界如果不早点想清楚，项目照样会越写越乱。

很多后台项目在权限设计上都会经历一个阶段: 一开始觉得只要登录就够了，后来页面越来越多、角色越来越多，接口权限判断开始四处散落。

Feathers.js 很适合做资源型接口，但只要后台系统开始出现列表页、筛选器和搜索框，params.query 很快就会从一小块对象膨胀成谁都不敢碰的入口。

Feathers.js 写着写着，大家迟早会遇到一个现实问题: 错误到底该在 hook 层拦，还是在 service 里抛，还是统一让框架接住以后再返回前端。

2021 年如果还在继续做 Node.js 后端，会明显感觉到一个趋势: 大家不再满足于“能把接口写出来”这件事了，而是开始追求更快搭后台、更容易扩展认证、更自然接入实时能力。

Feathers.js 在 2021 年让我觉得很有意思的一点，是它不是把实时能力当成“额外插件”，而是直接把 service 事件当成天然的推送源。

刚开始接触 Feathers.js 时，很多人会先被 service 和 hook 吸引，但真正把项目落地到后台管理系统，很快就会遇到一个更实际的问题: 登录链路到底怎么搭才不乱。