V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
推荐学习书目
Learn Python the Hard Way
Python Sites
PyPI - Python Package Index
http://diveintopython.org/toc/index.html
Pocoo
值得关注的项目
PyPy
Celery
Jinja2
Read the Docs
gevent
pyenv
virtualenv
Stackless Python
Beautiful Soup
结巴中文分词
Green Unicorn
Sentry
Shovel
Pyflakes
pytest
Python 编程
pep8 Checker
Styles
PEP 8
Google Python Style Guide
Code Style from The Hitchhiker's Guide
tangkikodo
V2EX  ›  Python

面向组合的 API 开发模式 - 以 FastAPI 为例

  •  
  •   tangkikodo · 327 天前 · 1828 次点击
    这是一个创建于 327 天前的主题,其中的信息可能已经有所发展或是发生改变。
    第 1 条附言  ·  327 天前
    现在流行的思路是借助 graphql, 但整套方案的引入成本对后端来说并不低. 并且前端还需要手写 query 来描述字段, 没有直接 rpc-like 的请求体验顺畅. (rpc-like 可以参考 openapi + typescript-openapi-codegen)

    面向组合的开发模式就是为了解决这个问题, 通过使用 pydantic-resolve 让 router 层负责构建 schema 来封装变化, 从而避免 service 和 client 的改动.
    5 条回复    2024-01-27 11:55:27 +08:00
    yuanxin1999
        1
    yuanxin1999  
       327 天前
    可以看看这个项目 https://github.com/luraproject/lura
    看起来思路差不多
    tangkikodo
        2
    tangkikodo  
    OP
       326 天前
    @yuanxin1999 侧重点不太一样, 这个模式期望在尽量不修改 service 模块的前提下,通过声明组合式的 schema , 来达到生成复杂结构数据的目的

    复杂结构包括拼接多种数据, 关联多层的嵌套关联数据 等等。
    onesec
        3
    onesec  
       322 天前
    我现在是用的 FastApi + GraphQL , 定义 Schema 会比较麻烦, 但比较爽的就是一个接口解决问题。GraphQL 查询时可以按需查询,所以相应的后端对于 Schema 定义可以适当冗余。
    tangkikodo
        4
    tangkikodo  
    OP
       319 天前
    @onesec 是的,graphql 的优点就是在后端比较稳定的情况下提供一套灵活的查询。

    graphql 这层东西有两面性,如果是迭代中调整比较多的项目, 比如要修改 schema , 那么对已有的 query 的调整就会比较麻烦。 后端的改动就会影响 gql 然后影响前端的 query 。
    第二点是 graphql 做性能调优会比较约束,一个 schema 可能被多种 query 都依赖, 不容易修改。
    第三点我觉得麻烦的是 管理 dataloader , 每个 request 都要初始化一下实例, 而且都要放在 context 一个 scope 里面, 时间久了 loader 管理就比较麻烦。pydantic-resolve 采用的是就地申明的做法, 不需要往某个 context 里面一股脑放进去。

    这些也是我想直接从 pydantic 扩展字段的原因,fastapi + openapi-typescript-codegen 直接面向前端提供接口。
    schema 的申明本身就类似 graphql query 。
    每个 schema 都可以继承扩展, 相当于每个 API 的 schema 都可以互相独立, 不产生耦合。
    最后, 因为是每个接口互相独立, 想做后续的性能优化和改动就会比较容易。
    tangkikodo
        5
    tangkikodo  
    OP
       319 天前
    @onesec 我用 pydantic-resolve 重写了 graphql 的接口, 功能上除了自我引用的场景,其他都能等价替换

    收益是去除了 graphql 框架的依赖, 并且自己在前端不用再写 query & mutation 了 (通过 sdk 直接调用方法)

    如果是自己全栈写项目,感觉比 graqphl 要简单些
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   4916 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 21ms · UTC 08:39 · PVG 16:39 · LAX 00:39 · JFK 03:39
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.