tangkikodo 最近的时间轴更新 tangkikodo 最近的时间轴更新 |
tangkikodoV2EX 第 291907 号会员，加入于 2018-02-13 14:40:00 +08:00 |
| 上次聊前后端分工还是有点空洞， 这次来贴一个 demo
1 Python • tangkikodo • 102 天前
|
| 从前后端分工的利弊谈起，聊聊这套分工的未来方向
1 程序员 • tangkikodo • 119 天前 • 最后回复来自 tangkikodo
|
32 |
| 从 restful 到 graphql， 从 rpc 到 pydantic-resolve， 谈谈前后端紧耦合项目接口的（可能）演进方向 程序员 • tangkikodo • 89 天前 • 最后回复来自 shujuliuer | 4 |
| 面向组合的 API 开发模式 - 以 FastAPI 为例 Python • tangkikodo • 283 天前 • 最后回复来自 tangkikodo | 5 |
| 异步构建嵌套数据的小工具库： pydantic-resolve
1 Python • tangkikodo • 2023-06-10 23:41:55 PM
|
| 如果你爱用 FastAPI, 那么这个轮子可能有用处。 Python • tangkikodo • 2023-04-07 23:27:12 PM • 最后回复来自 tangkikodo | 3 |
| [内推] 育碧中国，坐标上海徐汇漕河泾， Web 全栈开发，招募中。 酷工作 • tangkikodo • 2021-04-20 12:19:48 PM • 最后回复来自 wang9571 | 17 |
tangkikodo 最近回复了
102 天前 回复了 Irisxx 创建的主题 › 程序员 › 一个接口引发的前后端处理数据标准的思考 |
后端组合， 大概率后端自己也不喜欢拼数据所以想偷懒了。
https://github.com/allmonday/pydantic-resolve-demo 如果是 python 这边的话， 这种需求 pydantic-resolve 一把梭直接就能组合好。
https://github.com/allmonday/pydantic-resolve-demo 如果是 python 这边的话， 这种需求 pydantic-resolve 一把梭直接就能组合好。
116 天前 回复了 solaris2022 创建的主题 › React › 各位是如何写单元测试的，如何保证单元测试覆盖率 |
怎么写（单元）测试？
要从可测的思考方式来书写代码， 才有“可能”写测试
在写实现之前，或者实现之后里面套上测试， 否则久了就不会写了
要懂得常用的 mock 第三方接口的方法， 会构造数据整合查询一起测试
知道哪些应该写， 哪些没必要
知道怎么结合 use case 来写
知道怎么结合 hook 在 commit 之前强制测试跑通
知道怎么划分出合适的 service 层并覆盖测试， 避免在应用层写无聊的测试
想到更多了在补充。
关于只在 service 覆盖测试， 应用利用继承和组合避免测试， 可以参考
https://github.com/allmonday/composition-oriented-development-pattern/blob/master/src/services/sprint/readme-cn.md
要从可测的思考方式来书写代码， 才有“可能”写测试
在写实现之前，或者实现之后里面套上测试， 否则久了就不会写了
要懂得常用的 mock 第三方接口的方法， 会构造数据整合查询一起测试
知道哪些应该写， 哪些没必要
知道怎么结合 use case 来写
知道怎么结合 hook 在 commit 之前强制测试跑通
知道怎么划分出合适的 service 层并覆盖测试， 避免在应用层写无聊的测试
想到更多了在补充。
关于只在 service 覆盖测试， 应用利用继承和组合避免测试， 可以参考
https://github.com/allmonday/composition-oriented-development-pattern/blob/master/src/services/sprint/readme-cn.md
119 天前 回复了 tangkikodo 创建的主题 › 程序员 › 从前后端分工的利弊谈起，聊聊这套分工的未来方向 |
@fescover
是的 生态的优势非常重要
是的 生态的优势非常重要
120 天前 回复了 tangkikodo 创建的主题 › 程序员 › 从前后端分工的利弊谈起，聊聊这套分工的未来方向 |
@justdoit123
gql 的另一个问题是数据结构关联按照什么模式来组织
如果按照业务模型的方式组织， 那么面向具体的展示层， 很多查到的关联结构要在 UI 上重新做调整。
如果按照 UI 的需求来组织，那么这个 gql 写起来就很没劲了。。 变成了大号 rest
gql 的另一个问题是数据结构关联按照什么模式来组织
如果按照业务模型的方式组织， 那么面向具体的展示层， 很多查到的关联结构要在 UI 上重新做调整。
如果按照 UI 的需求来组织，那么这个 gql 写起来就很没劲了。。 变成了大号 rest
120 天前 回复了 tangkikodo 创建的主题 › 程序员 › 从前后端分工的利弊谈起，聊聊这套分工的未来方向 |
@ilvsxk
bff 如果不是前端去维护的话， 感觉这个 bff 的组织划分就有问题哎。。 （比如现在 node 就是 bff 的绝对优势语言（虽然我不太喜欢
本质上就是让前端自己组合出所需的数据， 避免不必要的组合逻辑侵入到前端展示层。
bff 如果不是前端去维护的话， 感觉这个 bff 的组织划分就有问题哎。。 （比如现在 node 就是 bff 的绝对优势语言（虽然我不太喜欢
本质上就是让前端自己组合出所需的数据， 避免不必要的组合逻辑侵入到前端展示层。
120 天前 回复了 tangkikodo 创建的主题 › 程序员 › 从前后端分工的利弊谈起，聊聊这套分工的未来方向 |
@justdoit123 完全同意
我觉得这个工具其实不是给前后端对接用的， 围绕着他的 DSL ，明明 语言原生就有的类型， 还得顺着它定义一套类型。 啰嗦了。
臃肿的请求，前端自己通过查询串联起来许多服务， 导致后端要调整的时候非常被动。
本来能用一个 client.load_xxx_data 搞定的事情， 还得在前端维护一大串查询， 这是对迭代很不友好的~
我觉得这个工具其实不是给前后端对接用的， 围绕着他的 DSL ，明明 语言原生就有的类型， 还得顺着它定义一套类型。 啰嗦了。
臃肿的请求，前端自己通过查询串联起来许多服务， 导致后端要调整的时候非常被动。
本来能用一个 client.load_xxx_data 搞定的事情， 还得在前端维护一大串查询， 这是对迭代很不友好的~
120 天前 回复了 tangkikodo 创建的主题 › 程序员 › 从前后端分工的利弊谈起，聊聊这套分工的未来方向 |
@ilvsxk bff 应该一头受气才对呀~~
120 天前 回复了 tangkikodo 创建的主题 › 程序员 › 从前后端分工的利弊谈起，聊聊这套分工的未来方向 |
@justdoit123
前后端都是 ts 技术栈， 就非常丝滑。
但缺点就是你不能指望啥都用 node 来写吧 ~~
另外光 trpc 也不能解决如何 高效且可维护地组合数据 这个问题， 如果能在 typescript 里面用
```
class Team {
member: Member[]
async resolve_member(loader=MemberLoader) {
return await loader.load(this.team_id)
}
}
```
这样地方法来组合数据， 也会优雅很多的
前后端都是 ts 技术栈， 就非常丝滑。
但缺点就是你不能指望啥都用 node 来写吧 ~~
另外光 trpc 也不能解决如何 高效且可维护地组合数据 这个问题， 如果能在 typescript 里面用
```
class Team {
member: Member[]
async resolve_member(loader=MemberLoader) {
return await loader.load(this.team_id)
}
}
```
这样地方法来组合数据， 也会优雅很多的
120 天前 回复了 tangkikodo 创建的主题 › 程序员 › 从前后端分工的利弊谈起，聊聊这套分工的未来方向 |
Select Language