说通俗一点，graphql 对于后端来说该写的接口还是要写，上了 graphql 后，后端的每个接口，变成了类似数据库表资源的存在，于是前端可以写出等价于 sql 的查询语句：

“ SELECT apiXXX1 WHERE arg1=aaaa AND arg2=bbbbb; SELECT .....”

等价于

{result1:apiXXX1(arg1:aaaa, arg2:bbbbb), result2: apiXXX2......}

前端同学的需求痛点是
1. graphql 可以一个请求完成对原先多次请求的查询，这样就不用 promise 等异步处理了。

但一般来说后端不用 graphql 也能做到一次请求性合并处理多个接口请求，无非是加一个循环而已。

2. graphql 可以通过 schema 约定接口请求与返回的强参数类型。

这个其实前后端本来就能通过接口文档的形式约定，原本是程序员基本素养问题，现在通过强制代码编写约定，我觉得可以提倡，但不少人会不乐意写因为麻烦。

3. graphql 可以过滤掉不需要的字段，减少网络带宽。

虽然减少网络带宽，但服务器查询执行业务的消耗仍旧不变，而且对于大部分业务来说，前端获取的数据越多越好，很少有人会为了省那点带宽干这事情。