• #22楼 @leiz_me 嗯,你说的有道理。这个模式目前在我们其中一个业务复杂度非常高的模块里应用得非常好,但也不是万金油,我们也在摸索什么项目里比较适合以及每个项目里用到什么程度比较适合。开发总是一个不断做 tradeoff 的过程。

  • #18楼 @Rei 估计已经不可考

  • #16楼 @Rei 这个确实不是社区共识,但事实上确实是初学者经常看到的东西,非常有必要辟个谣

  • #7楼 @nouse GraphQL 不一定要直接面对 DB 的表结构,虽然一开始这样会比较方便。在我看来 GraphQL 更像是一个 Data Aggregation Layer,DB 可能是主要的数据来源,但是 GraphQL 的 Resolver 可以允许任意的数据源,可以是 DB,也可以是自己的或者是第三方的 API,也可以是计算产生的数据,其实是可以很灵活的。GraphQL 维护起来当然成本不低,但考虑可维护性不能仅仅考虑这一层的可维护性,至少从现在看来,整体上,GraphQL 可以降低我们前端+移动端+后端+各种微服务数据+各种第三方服务数据这些加起来的可维护性,这对我们来说是很重要的。

  • #3楼 @aisensiy CSDN 那篇文章更多的是从客户端角度来思考这个问题的,并且我们希望引入 GraphQL 解决的问题也主要是从客户端和客户体验角度,以及从前后端合作、产品迭代速度的角度考虑,而并不是为了减少工程师的工作量。

    你提到的两个例子,正好是 Rest API 的 Data Over-fetching 和 Round Trips 的问题,也正是 GraphQL 着力解决的问题。这个对于 Web 来说可能问题不大,毕竟现在大家主要在桌面端用 Web 应用为主,但是对于移动端 API 来说这个就是个大问题,有可能我们的例子举得不够极端,但是在移动端,能少发一个请求,少传输一点数据,都是必要的,因为用的都是用户的流量。

    我觉得既然用了 GraphQL,细粒度的控制就是必要的代价,如果工程师(特别是后端工程师)的工作量增加,那也是值得的,至少从长远来看,不需要自定义 API 节点,也不需要每次前端移动端改点东西就要后端动手,总的工作量上不一定增加。

  • #4楼 @Rei “Fat Model, Thin Controller”不是Rails的指导原则,是社区前几年蛮流行的一个设计准则,基本上Google一下到处都是这个说法,我自己刚上手的时候也一直看到,所以我写的是 Rails 社区也有“Fat Model, Thin Controller”这样的指导原则 而不是 Rails 也有“Fat Model, Thin Controller”这样的指导原则

  • 昨天发出来之后也收到了一些反馈和疑问,所以对文章内容作了一些调整也添加了小部分内容 😎

  • 多谢各位支持,我就不一一回复了以免有刷评论嫌疑 😜

  • #1楼 @colorfulberry 多谢支持 💪

  • #48楼 @tcstory 来啊