@
AloneHero 这段我没描述清晰, 这两个 comment count 是为了比喻某种前端视图需求, 拿到了数据之后需要做二次统计聚合, 或者干脆要自己转换一把。 “解决 gql 不擅长的后处理环节” 是 gql 不适合前后端紧耦合这个大问题下面的子问题。
------ “那是不是某个字段的逻辑有可能分散在很多字段里面?这样可维护性会不会很容易遭到破坏?”
你对 gql 很熟悉, 会想到这个问题,我猜是从 qgl 中 schema 是复用的情况下产生的疑问。在 resolve 的模式下,schema 是通过继承**核心数据**的结构, 来保证每个结构都有一套自己的描述。( pick 数据也能支持)
比如一个页面用到的 schema , 是在同级目录下按需申明出来的, 所以后处理的依赖关系挺清晰的。
比较真实的例子可以看
-
https://github.com/allmonday/composition-oriented-development-pattern/blob/master/src/router/sample_1/schema.py 介绍了使用继承来“clone" schema 的做法。
我在“优势” 中说,gql 和 restuful 适合提供公共接口, 是因为公共接口往往设计合理,也不用考虑太多视图层数据的特殊展示需求。gql 根据查询来驱动的特性决定了这种后处理字段的依赖关系会造成混乱(单独查询 count 总不能暗搓搓去触发 blogs 吧),gql 构造业务向的数据,可能的后果是, 提供了 90%前端所要的结构, 但剩下 10% (不准确,比喻)涉及到后处理相关的,gql 做和前端做, 都挺麻烦的。 再加上前端需要随时跟着后端调整 query ,形成了迭代中的负担。
pydantic-resolve 的例子里面, 可以理解为, 前端描述的 query 直接固化在了后端 schema 上。
这时前端只要向 rpc 那样直接`getSiteData` 就能拿到视图数据, 如果迭代中出现需求, 需要在这个视图数据上添加额外数据,比如后处理按照层级统计 count , 或者把结构做转换, 后端都很容易,并且改完之后前端同步一下就能感知。
里面比较极端的例子就是文末彩蛋处理 tree 的层层聚合。
pydantic-resolve 的角色是扮演好防腐层, 提供各种功能来做好“数据获取和转换” 这个目的, 然后尽可能避免 service 做调整。