@StarkWhite 看迭代的变化程度， 如果是增减字段还是 ok 的， 如果接口要做大变化的话， 我感觉维护 query 也是额外成本。

给 client 一种这么灵活的工具， 有时搞不好会玩出花最后不好维护。 比如本来可以通过一个新接口+过滤来获取的数据，client 为了图方便避免沟通， 走了一个绕路的查询， 而路径长的查询又可能引起性能问题。

@Mithril 找到看法相同的了~ 握手

作为一个查询语言，gql 是个后端请求数据聚合的好帮手 （但也有问题， 比如做层级聚合）

但把这查询语言暴露给 client 就离大谱了 （除非做 github, jira 这种固定需求的 client ）

这约等于后端把业务处理的控制权分散了出去，client 拼个夸张的 query 之后， 过来说功能交付了， 但是性能不行， 你帮我优化优化。 这可就刺激了。

gql 也好，orm 也好， 都只做了层层向下关联数据的事情， 并不负责从查询到的数据， 转换为前端所真正需要的视图这一块。

如果使用 python 的话， 可以尝试一下 pydantic-resolve. https://allmonday.github.io/pydantic-resolve/dataloader/

解决的就是这种，即负责关联数据的获取， 同时还能处理数据转换，然后再使用最朴素的传统接口返回。

@StarkWhite gql 社区资源是真的丰富

不过 gql 拿来给 client 提供 api 是会有点问题的， 除非是 api 先行， 开发完了也不用调整的这种项目。

否则迭代也会疼

apijson 或者 graphql 作为查询层的功能， 放在 client 很容易出现不合适的情况。

个人觉得放到后端或者 bff 层， 保持独立固定的接口， 才能做好总体业务的维护。

@frankies 流量为王的时代， 正向口碑和反向口碑， 反正能引流， 吵架也能引流
作者在营销上， 算是豁出去了。

现在前后端分离上很多方案都点歪了科技树， 前端总想多做点业务层的事情， 后端总想给点万能接口...

但实际上， 前端，或者说 UI ， 应该只是业务数据的一种具体实现， 是核心业务的外层 presenter 层， 讲道理就是应该稍作业务逻辑处理相关的事情的。

都暴力推荐了， 那就顺带也推荐个后端驱动的 API 构建工具吧~~
肥肠小巧 https://allmonday.github.io/pydantic-resolve/

@metavoidx
同意的， 我其实因为是个 sqlalchemy 苦手， 感觉配置 relationship 之类的太繁琐了，就刻意从这层脱身出来 囧

hi, 我是 pydantic-resolve 作者（也是那篇 composition oriented development pattern 的作者) ， 在声明式描述数据这点上我很赞同你的观点， 我观点上的一些分歧在于是否应该和 ORM 关联的紧密，下面是我的解释。

首先，既然用申明方式来生成数据， 目的肯定是为了更加优雅的组合数据

一般来说， 后端生成一个前端直接可用的视图数据包括几个步骤。
1. 数据获取
2. 数据组装 (utilmeta 把 1 ，2 两个环节一次性解决了）
3. 面向业务进行转换 这么几个步骤。

（一般情况下 2 ，3 可能会混在一起）

我选择使用 dataloader 的原因是：

通过 ORM 获取关联数据的手段之一，这个行为如果用通用的描述来说的话， 类似于：

def batch_query(keys, filters) 然后把查询结果绑定回每一条父记录。

这样在一对多查找的时候，既能使用外键， 还能指定额外过滤条件
https://github.com/allmonday/composition-oriented-development-pattern/blob/master/src/router/sample_2/readme-cn.md

( ORM relationship 上添加额外条件的查询写起来通常都会比较繁杂）

也就是说，loader 的内部实现可能是一段查询， 也可能是一个 rpc ， 也可能是缓存查询 等等

这样做的好处是隔离了具体实现， 假如我要做服务拆分的话， 就能将封装的查询，转成一个 rpc 调用了。

关于 3 ， 数据转换， 这也是直接从 ORM 拼装数据可能存在的一个小问题， 如果视图数据需要对视图数据的中间， 或者底层的数据做些转换， 聚合计算之类的功能， 很多时候就不得不拆开来遍历计算了。

pydantic-resolve 的思路是选择使用 post_method 来在每层提供一个 after resolved hook 来操作数据。 用来处理层级聚合， 字段转换会比较方便， 也符合声明式的风格。
https://github.com/allmonday/composition-oriented-development-pattern/blob/master/src/router/sample_4/readme-cn.md

说了一些拙见，框架本身是服务于特定目的，

utilmeta 这样的申明式方法带来了很好的灵活性和使用便利。

而且被你详细的文档和丰富的 example 给震撼到了！

祝蒸蒸日上

https://github.com/allmonday/pydantic-resolve 可以试试， 用 RESTful + 申明式的类型描述来生成组合数据。

@onesec 我用 pydantic-resolve 重写了 graphql 的接口， 功能上除了自我引用的场景，其他都能等价替换

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

如果是自己全栈写项目，感觉比 graqphl 要简单些

@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 都可以互相独立， 不产生耦合。
最后， 因为是每个接口互相独立， 想做后续的性能优化和改动就会比较容易。

@yuanxin1999 侧重点不太一样， 这个模式期望在尽量不修改 service 模块的前提下，通过声明组合式的 schema ， 来达到生成复杂结构数据的目的

复杂结构包括拼接多种数据， 关联多层的嵌套关联数据 等等。

罗列了一些和其他方案相比优缺点的比较。

https://github.com/allmonday/pydantic-resolve/blob/master/doc/compare-cn.md

其实不用 FastAPI 这个库也能解决不少问题。
只是如果搭配 FastAPI, response_model 再外加 基于 openapi.json 的 client 生成。 前后端开发体验直接飞升~

ref:
https://fastapi.tiangolo.com/advanced/generate-clients/

@wang9571 中英文都要的

@imhd 你确定~~？

@Willem97
@matrix1986
容器化部署，说实话现在 Go 还是玩票性质，也欢迎大佬带飞~

@devlaiho 不介意的话来个简历，互相合适的话聊聊~

@ch2 有，戳： https://mp.weixin.qq.com/s/s_KSZrTHnfS6q9rbmQPb-w