tangkikodo 最近的时间轴更新 tangkikodo 最近的时间轴更新 | tangkikodoV2EX 第 291907 号会员，加入于 2018-02-13 14:40:00 +08:00今日活跃度排名 25059 |
| fastapi-router-viz, 可视化你的 API 内依赖关系 Python tangkikodo 5 天前 最后回复来自 tangkikodo | 7 |
| Resolver 模式，一种比 GraphQL 适用于 BFF 的新选择 1 Python tangkikodo 86 天前 最后回复来自 tangkikodo | 4 |
| 上次聊前后端分工还是有点空洞， 这次来贴一个 demo 1 Python tangkikodo 2024-07-25 16:57:02 PM |
| 从前后端分工的利弊谈起，聊聊这套分工的未来方向 1 程序员 tangkikodo 47 天前 最后回复来自 mouyase | 33 |
| 从 restful 到 graphql， 从 rpc 到 pydantic-resolve， 谈谈前后端紧耦合项目接口的（可能）演进方向 程序员 tangkikodo 2024-08-07 16:38:09 PM 最后回复来自 shujuliuer | 4 |
| 面向组合的 API 开发模式 - 以 FastAPI 为例 Python tangkikodo 2024-01-27 11:55:27 AM 最后回复来自 tangkikodo | 5 |
| 异步构建嵌套数据的小工具库： pydantic-resolve 1 Python tangkikodo 2023-06-10 23:4155 PM |
| 如果你爱用 FastAPI, 那么这个轮子可能有用处。 Python tangkikodo 2023-04-07 23:27:12 PM 最后回复来自 tangkikodo | 3 |
tangkikodo 最近回复了
5 天前 回复了 tangkikodo 创建的主题 Python fastapi-router-viz, 可视化你的 API 内依赖关系 |
改了个名字：fastapi-voyager
5 天前 回复了 tangkikodo 创建的主题 Python fastapi-router-viz, 可视化你的 API 内依赖关系 |
@3085570450tt 确实， 当局者迷了
6 天前 回复了 tangkikodo 创建的主题 Python fastapi-router-viz, 可视化你的 API 内依赖关系 |
6 天前 回复了 tangkikodo 创建的主题 Python fastapi-router-viz, 可视化你的 API 内依赖关系 |
支持生成 dot 文件， 转换成 mermaid 语法的话要找一些 dot2mermaid 的小工具
86 天前 回复了 tangkikodo 创建的主题 Python Resolver 模式，一种比 GraphQL 适用于 BFF 的新选择 |
@pluswu1986 是的，最后苦果还得自己吞。。
114 天前 回复了 tangkikodo 创建的主题 Python Resolver 模式，一种比 GraphQL 适用于 BFF 的新选择 |
@seansong 和 GraphQL 那些技术栈和框架相比算不了太工程化吧
现在 pydantic v2 的性能也足够强了，pydantic-resolve 的行为类似于给字段提供数据获取 和 修改的 hook 方法
就这么两个 “规则”
现在 pydantic v2 的性能也足够强了，pydantic-resolve 的行为类似于给字段提供数据获取 和 修改的 hook 方法
就这么两个 “规则”
2024-07-25 21:06:45 +08:00 回复了 Irisxx 创建的主题 程序员 一个接口引发的前后端处理数据标准的思考 |
后端组合， 大概率后端自己也不喜欢拼数据所以想偷懒了。
https://github.com/allmonday/pydantic-resolve-demo 如果是 python 这边的话， 这种需求 pydantic-resolve 一把梭直接就能组合好。
https://github.com/allmonday/pydantic-resolve-demo 如果是 python 这边的话， 这种需求 pydantic-resolve 一把梭直接就能组合好。
2024-07-11 20:05:49 +08:00 回复了 solaris2022 创建的主题 React 各位是如何写单元测试的，如何保证单元测试覆盖率 |
怎么写（单元）测试？
要从可测的思考方式来书写代码， 才有“可能”写测试
在写实现之前，或者实现之后里面套上测试， 否则久了就不会写了
要懂得常用的 mock 第三方接口的方法， 会构造数据整合查询一起测试
知道哪些应该写， 哪些没必要
知道怎么结合 use case 来写
知道怎么结合 hook 在 commit 之前强制测试跑通
知道怎么划分出合适的 service 层并覆盖测试， 避免在应用层写无聊的测试
想到更多了在补充。
关于只在 service 覆盖测试， 应用利用继承和组合避免测试， 可以参考
https://github.com/allmonday/composition-oriented-development-pattern/blob/master/sr/services/sprint/readme-cn.md
要从可测的思考方式来书写代码， 才有“可能”写测试
在写实现之前，或者实现之后里面套上测试， 否则久了就不会写了
要懂得常用的 mock 第三方接口的方法， 会构造数据整合查询一起测试
知道哪些应该写， 哪些没必要
知道怎么结合 use case 来写
知道怎么结合 hook 在 commit 之前强制测试跑通
知道怎么划分出合适的 service 层并覆盖测试， 避免在应用层写无聊的测试
想到更多了在补充。
关于只在 service 覆盖测试， 应用利用继承和组合避免测试， 可以参考
https://github.com/allmonday/composition-oriented-development-pattern/blob/master/sr/services/sprint/readme-cn.md
2024-07-08 19:58:23 +08:00 回复了 tangkikodo 创建的主题 程序员 从前后端分工的利弊谈起，聊聊这套分工的未来方向 |
@fescover
是的 生态的优势非常重要
是的 生态的优势非常重要
Select Language