@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