tangkikodo's recent timeline updates
tangkikodo

tangkikodo

V2EX member #291907, joined on 2018-02-13 14:40:00 +08:00
fastapi-router-viz, 可视化你的 API 内依赖关系
Python  •  tangkikodo  •  Nov 6, 2025  •  Lastly replied by workshop
8
Resolver 模式,一种比 GraphQL 适用于 BFF 的新选择
  •  1   
    Python  •  tangkikodo  •  Jul 15, 2025  •  Lastly replied by tangkikodo
    4
    从前后端分工的利弊谈起,聊聊这套分工的未来方向
  •  1   
    程序员  •  tangkikodo  •  Aug 23, 2025  •  Lastly replied by mouyase
    33
    tangkikodo's recent replies
    @pf94 Data -> Repo -> Service -> Controller

    是的,这个是经典做法, 毕竟实现单向依赖的前提就是合理的分层

    我的这个方法是借助 dataloader 这样的工具将 repo 层的能力提高,controller 中组合数据的过程更加流畅
    @dearmymy 谢谢
    @ruanimal 分离业务复杂度和代码复杂度, 因为业务软件的核心资产是业务模型和用例。 很多时候业务模型和代码实现互相侵入, 依赖关系错综复杂, 导致业务迭代困难
    @llsquaer 中间表在业务描述的时候是不需要被产品等人员知晓的, 他们只要知道 voyager 从 A -> B 的关系, 如果用 DB ERD 的话, 这个中间表(技术实现细节)是会被展示出来的。

    扯到中间表是为了引入一些案例来说明业务模型和 db 模型不是完全一一对应的, 中间表数据具体的技术实现, 比如还能替换成其他做法, 比如(不严谨) A 中存放 list of b_ids ,B 中存放 list of a_ids.
    @xhawk 嗯,明白了。 我之前也想做 service 调用的分析, 但是复杂度太高了, 后来用 pydantic-resolve 实现了某种平替, 一个 service 返回的类型, 来间接代表这个 service 。 因为后端很多场景本质都是数据的组合, 如果数据类型是清晰的, 那么通过什么具体获取方式反而不是这么重要了。

    比如 Project 类型 通过 load_project 来获取, 那么我只要知晓组合的是 Project 或者 subset of Project , 那我其实也间接知道了调用链条。

    仅供参考~
    @xhawk 有兴趣的话可以也试试 pydantic-resolve, voyager 其实是为它量身定做的~
    @xhawk 不客气~~
    改了个名字:fastapi-voyager
    @3085570450tt 确实, 当局者迷了
    @yb2313 fastapi 现在迭代进度明显减慢了, 确实相比之下 litestar 功能相当丰富

    回头如果有需要, 去移植个 litestar-router-viz ~
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   5318 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 01:21 · PVG 09:21 · LAX 18:21 · JFK 21:21
    ♥ Do have faith in what you're doing.