推荐学习书目 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
这是一个创建于 630 天前的主题，其中的信息可能已经有所发展或是发生改变。
第 1 条附言 2024-01-19 10:37:35 +08:00
现在流行的思路是借助 graphql, 但整套方案的引入成本对后端来说并不低. 并且前端还需要手写 query 来描述字段, 没有直接 rpc-like 的请求体验顺畅. (rpc-like 可以参考 openapi + typescript-openapi-codegen)
面向组合的开发模式就是为了解决这个问题, 通过使用 pydantic-resolve 让 router 层负责构建 schema 来封装变化, 从而避免 service 和 client 的改动.
面向组合的开发模式就是为了解决这个问题, 通过使用 pydantic-resolve 让 router 层负责构建 schema 来封装变化, 从而避免 service 和 client 的改动.
 | 1 yuanxin1999 2024-01-19 10:40:43 +08:00 可以看看这个项目 https://github.com/luraproject/lura 看起来思路差不多 |
 | 2 tangkikodo OP @yuanxin1999 侧重点不太一样， 这个模式期望在尽量不修改 service 模块的前提下，通过声明组合式的 schema ， 来达到生成复杂结构数据的目的 复杂结构包括拼接多种数据， 关联多层的嵌套关联数据 等等。 |
 | 3 onesec 2024-01-24 10:27:38 +0:00 我现在是用的 FastApi + GraphQL ， 定义 Schema 会比较麻烦， 但比较爽的就是一个接口解决问题。GraphQL 查询时可以按需查询，所以相应的后端对于 Schema 定义可以适当冗余。 |
| 4 tangkikodo OP @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 都可以互相独立， 不产生耦合。 最后， 因为是每个接口互相独立， 想做后续的性能优化和改动就会比较容易。 |
| 5 tangkikodo OP @onesec 我用 pydantic-resolve 重写了 graphql 的接口， 功能上除了自我引用的场景，其他都能等价替换 收益是去除了 graphql 框架的依赖， 并且自己在前端不用再写 query & mutation 了 （通过 sdk 直接调用方法） 如果是自己全栈写项目，感觉比 graqphl 要简单些 |
Select Language