新手问题 关于 GraphQL Query 的一个问题
传统的 restful 实现 返回 users 一般至少要两个接口
/user/id
/users
迁移到 graphql 基本就变成了
fields: {
user: {
type: userType,
description: 'Returns a single user',
args: {
id: {type: GraphQLString}
},
resolve: function (_, args) {
return UserService.findOne(args.id);
}
},
users: {
type: new GraphQLList(userType),
description: 'Returns a list of users',
resolve: function () {
return UserService.find()
}
}
}
但是这里有个盲点是，restful 是因为字段都是后端决定的，导致查找同一个对象必须要两个接口来适应的不同的页面
在 graphql 里面一个 query 返回的字段是由前端决定的， users 可以提供的信息 能够看做 user 接口的超集。 在这种情况下 感觉单独的 user 接口已经没有存在的必要， 但是很多地方，包括某些教程里 都会 拿 user 和 users 的接口作为案例。
问题来了 graphql 下 user 的 query 是否任有存在的必要性
robot_zhang
回复
你说的点我都考虑过，因为列表接口内的权限控制是必不可少的，加个详情页的接口并不能方便做权限，反而要额外做权限。
前端处理简单点，事实上返回的数据接口只是从原来的处理方式只是外面套了一层 []，这一点工作量确实后端有必要去额外写一个接口吗
data: {}
变成了
data:[{}]
理论上是不需要的，但实际上，后端还没有智能到可以把处理 collection 和单条记录一样高效，比如 collection 的查询，都需要分页信息之类，虽然在 gql 这层是可以不查的，但后端同样需要 count 一次。
权限不是一个问题，gql 之后，权限其实不是基于 action 的，是基于 RLS 或 ACL 的。
这其实是个 API 设计问题，和是不是 GraphQL 关系不大。RESTful api 也可以设计成 /users?id=1&fields=id,name,email 这种形式，这样一个 RESTful API 也能完成要求。restful 是因为字段都是后端决定的，导致查找同一个对象必须要两个接口来适应的不同的页面 这句话是不对的。RESTful 也可以用 fields 字段来选择返回的字段，GraphQL 也可以只用一个 fragment 来"永远"返回相同的结构。GraphQL 相对于 RESTful 来说解决的问题主要要在更上一层，一个 API 返回多种 Resource 的时候。