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