做前后端分离接口开发时，用 graphql 的多吗？

至少你说的这俩都算不上什么优点。。。
1. 稍微复杂点的需求都不可能自动生成接口。除非你打算直接把数据库暴露出去。但这么干为啥不直接 Node JS 里上 ORM 一把梭？反正都是前端可以解决的需求。如果有后端计算或者复杂的多服务交互需求，GraphQL 都得自己写。
2. 本质上和 1 是一个问题，数据结构足够简单而且数据库足够小的话就可以随便自动生成。数据量大了你就得自己写。比如你返回个列表，每个对象会返回一个关联查询的其他对象。自动生成的话它就是先查出来第一个列表，然后每个列表对象做一次查询。这种你得自己写 data loader 。

公司有个项目在用 graphql，总而言之麻烦多多，说不上一塌糊涂，但也差不多了。
一个东西不流行，一定是这个东西本身有问题。

还有就是这个东西极大增加前端工作量，x5 x10 这种程度的增加，如果你推动 graphql 落地，你肯定和前端混不下去了。

@Mithril 可以了解一下 hasura[https://hasura.io/],应该可以减少 70%的手动编码量吧。

@yaphets666 用不用 graphql，前端不都要写调用 api 部分的代码吗？

@chengdonghui 模糊查询啊 各种拼接 sql 都要前端来 你觉得没问题你就试试

@chengdonghui 你再仔细看看我说的，70%是不可能的。除非你需要在后端处理的业务逻辑几乎没有，这就相当于前端直连数据库。
但你业务都简化到这种程度了，为啥不直接把后端全砍掉前端直接 node.js 里上 ORM ？

不懂就问，这个和我自定义一套查询协议有什么区别呢？我们公司也是有自己的查询协议，每个服务的基础协议都是一直的，然后我们做了一个数据查询服务的中间件，聚合了其它所有的能提供数据的微服务，然后根据业务需要归纳需要支持的查询场景，由这个中间件支持列表，嵌套查询，关联查询，聚合查询等，同时这个中间件也是支持 dataLoader，可以自己接入数据源

来看下，怎么说服领导，放弃 graphql，简直坑害前端同事。

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

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

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

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

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

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

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