tangkikodo

后端组合， 大概率后端自己也不喜欢拼数据所以想偷懒了。

https://github.com/allmonday/pydantic-resolve-demo 如果是 python 这边的话， 这种需求 pydantic-resolve 一把梭直接就能组合好。

怎么写（单元）测试？

要从可测的思考方式来书写代码， 才有“可能”写测试

在写实现之前，或者实现之后里面套上测试， 否则久了就不会写了

要懂得常用的 mock 第三方接口的方法， 会构造数据整合查询一起测试

知道哪些应该写， 哪些没必要

知道怎么结合 use case 来写

知道怎么结合 hook 在 commit 之前强制测试跑通

知道怎么划分出合适的 service 层并覆盖测试， 避免在应用层写无聊的测试

想到更多了在补充。

关于只在 service 覆盖测试， 应用利用继承和组合避免测试， 可以参考
https://github.com/allmonday/composition-oriented-development-pattern/blob/master/src/services/sprint/readme-cn.md

@fescover
是的 生态的优势非常重要

@justdoit123

gql 的另一个问题是数据结构关联按照什么模式来组织

如果按照业务模型的方式组织， 那么面向具体的展示层， 很多查到的关联结构要在 UI 上重新做调整。

如果按照 UI 的需求来组织，那么这个 gql 写起来就很没劲了。。 变成了大号 rest

@ilvsxk

bff 如果不是前端去维护的话， 感觉这个 bff 的组织划分就有问题哎。。 （比如现在 node 就是 bff 的绝对优势语言（虽然我不太喜欢

本质上就是让前端自己组合出所需的数据， 避免不必要的组合逻辑侵入到前端展示层。

@justdoit123 完全同意

我觉得这个工具其实不是给前后端对接用的， 围绕着他的 DSL ，明明 语言原生就有的类型， 还得顺着它定义一套类型。 啰嗦了。

臃肿的请求，前端自己通过查询串联起来许多服务， 导致后端要调整的时候非常被动。

本来能用一个 client.load_xxx_data 搞定的事情， 还得在前端维护一大串查询， 这是对迭代很不友好的~

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

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

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

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

```
class Team {

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

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