这种 graphQL 的接口定义方式是一种好的实践吗?

我是前端，最近有机会跟一位全栈大牛合作项目，他在项目里用 graphql-java 定义实体的各字段（可能是定义 schema 和 model 吧），用一些注解的方式限制字段的创建修改权限等，然后自动生成了 graphql 和 sql 的 CURD 语句。

最终提供给前端的接口不是我常见的 restful 接口，而是向一个固定的 /query 接口（增删改是另一个接口）发请求，在 body 中传入一个类似如下的纯文本作为入参:

{
    goods(page:1,size:10,keyword:cola){
        id
        name
        brand
        desc
    }
    brands(page:1,size:20){
    	id
        name
    }
}

就能得到以下 json 出参:

{
    "code": 0,
    "message": "success",
    "data": {
        "goods": [{
            "id": 1,
            "name": "COCA COLA",
            "brand": "COCA COLA CORP.",
            "desc": "blablabla"
         },{
            "id": 2,
            "name": "PEPSI COLA",
            "brand": "PEPSI COLA CORP.",
            "desc": "blablabla"
         }],
         "brands": [{
            "id": 1,
            "name": "COCA COLA CORP.",
         },{
            "id": 2,
            "name": "PEPSI COLA CORP.",
         }{
            "id": 3,
            "name": "WAHAHA CORP.",
         }]
    }
}

我认为这种接口定义方式，等同于让前端自己写 SQL 语句，想查什么自己写入参就好了，将海量的自由度赋予了前端。虽然减轻了后台写 CURD 接口的负担，但我觉得可能会带来更多的问题和隐患。

具体有什么问题我也说不好，只提了 2 个问题。一个是如何防范前端非授权访问，影响数据库性能，或者篡改数据？另一个是怎么抵御别人爬数据库？大牛用限制访问频次、“特殊字段根据请求角色过滤”、数据库内存缓存、“特殊接口仍需自己写”等把我的问题顶回去了。。

我想问的是，这种接口定义方式是一种好的实践吗？哪些大厂在这么用？

Smilecc

2018-09-03 09:40:20 +08:00

首先 GraphQL 完全不等同于让前端自己写 SQL 语句，因为数据的组织还是来自于后端，后端仍然有绝对的数据控制权。
对于授权的问题，我的实践是这方面可以和 JWT 结合，把用户角色写入 token 中，在特殊字段 resolve 之前鉴权。
性能的问题，我认为使用 GraphQL 确实一定程度上会降低程序的性能，但可以通过加机器解决嘛，好处大于坏处吧。