@ilvsxk bff 应该一头受气才对呀~~

@justdoit123
前后端都是 ts 技术栈， 就非常丝滑。

但缺点就是你不能指望啥都用 node 来写吧 ~~

另外光 trpc 也不能解决如何 高效且可维护地组合数据 这个问题， 如果能在 typescript 里面用

```
class Team {

member: Member[]
async resolve_member(loader=MemberLoader) {
return await loader.load(this.team_id)
}
}
```

这样地方法来组合数据， 也会优雅很多的

@yrj

调整心态吧， 有句话说“业务逻辑是最不讲逻辑的”

在没有深度分析的情况下， 写 hard code 反而不失为一种最佳做法。

如果业务是个比萨斜塔， 代码可能就是“高质量”的定制化支架。 囧

@lingo 已经 star 啦。

我用 rsshub 的数据做持久化之后， 根据自己的 mark 历史， 在尝试构建自己的信息茧房 ~~

@yrj 如果发现 service 层都会反复变更的话=。=

事情就难办咯

@SenseHu 架构整洁之道常看常新， 之前对依赖关系的描述还比较迷茫， 最近终于弄明白了。

这个模式也是受了 DDD 的很多影响， 我也挺想总结为一套 clean architecture：）

@yrj

我对业务逻辑反复变更的观点是， 这是一个悲观主义者一定要考虑的情况。

这也是为什么我觉得面向 OPENAPI 的 RESTful 接口 和 openapi-ts 之类的 client generator 的组合是所有方案中， 对前端展示层跟随变动最友好的方式了。

不使用 client generator 的话， 前端变更简直火葬场

使用 graphql 的话， 前端跟着还要调整维护 query ， 也是包袱。

但如果不维护这层，后端也不主动提供页面专供接口， 那后果必然是前端拼拼凑凑，混入很多业务逻辑。

另外 BFF 这层防腐层， 看情况是可以放在后端的， 使用继承扩展 schema + resolver 的手段， 后端也能够轻松的构建 前端视图结构。 （这就看组织架构上， 根据开发资源决定哪边更适合做了）

比如我们的项目就是把这个组合层放在后端 router / controller 。

@jones2000
是的，数据库设计和合理的领域模型设计是核心， 这个应该是后端 service 层聚焦的东西。

独立的 bff 层或者 单体应用中的 controller 层聚焦的就是合理地组合 service

因此， 如果 service 层抽象的比较烂， 做的不稳定， 后面的人总归会比较惨

@FYFX

bff/controller 层做的事情，以 V2EX 为
简单来描述是 1. 先获取主数据，以 blog 为例就是先获取 blogs, 2. 根据 schema 里面的扩展定义获取 comments ，浏览量等数据

如果会出性能问题， 一般是主数据的量太大了， 比如没有采用分页方案，blog 获取了 1w 条， 那么对应的 dataloader batch 查询 就要处理 1w 个 blog_id 的参数， 这种性能问题的优化就是按照实际需要取主数据， 控制数量。

batch 查询的接口也可以对热点数据做缓存。

另外 resolver 的优点是组合灵活， 新增关联不需要去考虑 model/entity 层，ORM 那边定义新的 relationship 。

但随着业务稳定下来以后， 性能优化的时候， 是可以逐步替换， 切换成 ORM 直接提供关联数据。

（这也是为什么强调 API 要互相独立， 这样才能纵向的， 互不影响地优化 API ）

@jones2000 是的， 所以抽新的层一定要有必要才做

bff 的模式已经在很多公司采用， 客观说明了这层的价值。

让后端专注在服务， 前端专注在拼接和展示。（避免了后端为了响应 UI 层需求频繁调整接口的情景）

不稳定的层一定要依赖于稳定的层， 因此后端的服务接口质量就尤为重要了

@helbing 好巧~

没有最好的工具， 只有最适合的工具，graphql 现在就处在被人当成最好的工具的“光环”中， 近年来也开始有人来祛魅

在前后端开发中实践了 1 年 graphql 后， 我觉得 graphql 太重了， 而且向展示层暴露查询是一种危险的做法， 会反过来绑架后端的开发。

fastapi 中 pydantic 本身就能定义类型， 处理数据加载和校验， 所以动起了用 pydantic + resolve +dataloader 构建一个后端定义数据， 加载数据， 这样一套模式的脑筋。（阉割版本的 graphql, 笑)

实际使用体验非常不错。 当 schema 是固定的之后， 可以玩很多树状结构跨代的数据传输和收集， 在保持 service 提供数据不变的情况下， 满足各种展示层鬼畜的数据组合需求

后端接口质量不过关，并且 leader 不重视， 前端只能遭罪了。

我们 team 也不大， 但是 service 层功能的 testcase 非常重视，单测，mock 数据的集成测试， 这是这两点就让接口质量稳定了许多。

rsshub yyds

其实做 feed 的持久化， 然后平时搜索搜索信息也挺有用的

@AloneHero

这段我没描述清晰， 这两个 comment count 是为了比喻某种前端视图需求， 拿到了数据之后需要做二次统计聚合， 或者干脆要自己转换一把。 “解决 gql 不擅长的后处理环节” 是 gql 不适合前后端紧耦合这个大问题下面的子问题。


------ “那是不是某个字段的逻辑有可能分散在很多字段里面？这样可维护性会不会很容易遭到破坏？”

你对 gql 很熟悉， 会想到这个问题，我猜是从 qgl 中 schema 是复用的情况下产生的疑问。在 resolve 的模式下，schema 是通过继承**核心数据**的结构， 来保证每个结构都有一套自己的描述。（ pick 数据也能支持）
比如一个页面用到的 schema ， 是在同级目录下按需申明出来的， 所以后处理的依赖关系挺清晰的。

比较真实的例子可以看

- https://github.com/allmonday/composition-oriented-development-pattern/blob/master/src/router/sample_1/schema.py 介绍了使用继承来“clone" schema 的做法。


我在“优势” 中说，gql 和 restuful 适合提供公共接口， 是因为公共接口往往设计合理，也不用考虑太多视图层数据的特殊展示需求。gql 根据查询来驱动的特性决定了这种后处理字段的依赖关系会造成混乱（单独查询 count 总不能暗搓搓去触发 blogs 吧），gql 构造业务向的数据，可能的后果是， 提供了 90%前端所要的结构， 但剩下 10% （不准确，比喻）涉及到后处理相关的，gql 做和前端做， 都挺麻烦的。 再加上前端需要随时跟着后端调整 query ，形成了迭代中的负担。

pydantic-resolve 的例子里面， 可以理解为， 前端描述的 query 直接固化在了后端 schema 上。

这时前端只要向 rpc 那样直接`getSiteData` 就能拿到视图数据， 如果迭代中出现需求， 需要在这个视图数据上添加额外数据，比如后处理按照层级统计 count ， 或者把结构做转换， 后端都很容易，并且改完之后前端同步一下就能感知。

里面比较极端的例子就是文末彩蛋处理 tree 的层层聚合。

pydantic-resolve 的角色是扮演好防腐层， 提供各种功能来做好“数据获取和转换” 这个目的， 然后尽可能避免 service 做调整。

@qwerasdf123 这份执着也真的只能佩服

@StarkWhite 复杂度不能消灭， 只能控制。

从关注点分离的角度， 以及自己的体会来看， 这块复杂度我希望放在后端来管控

而“前端自己要做数据转换”， 这件事在前后端分离的项目中， 就是容易积累“技术债” 和 “遗留代码” 的地方。

@StarkWhite gql 本身没问题， 问题出在 gql 查询到的字段要转换成前端直接可用的结构， 往往是会有落差的。
因为后端结构相对固定， 但是前端视图数据却是各种天马行空。

如果不是具体专供的 gql 接口的话， 前端做转换的工作量一般都是存在的。
如果是专供接口的话， 那前端重写一遍 query 就有点多余。

这是我使用的一些感受~

@qwerasdf123 在项目中体验过 gql 之后，得出了这个工具，要用也是应该放在后端代理查询， 用最简洁的形式和前端做沟通。 这样如果请求有性能问题， 后端也有足够的方案来优化， 代替。

以一个个功能明确的 API 的方式， 类似 gql 查询， 但是前端不同提供描述， 如果有 ts sdk 传递类型信息会更好。

如果是 python 后端的话， 推荐一把 pydantic-resolve ，面向前后端一同迭代的场景，通过构建前端恰好可用的视图数据， 让前端专注在展现和交互功能上。