pagination - GraphQL 业务层中的列表和分页授权

Question

在 Dan Schafer 的优秀作品中 "GraphQL at Facebook" talk from React Europe他讨论了业务层模型中的集中授权如何避免必须为通向授权节点的每个边缘复制授权逻辑的问题。



这适用于类似 Todo.getById(1) 的东西在我的情况下，最终查询数据库 SELECT * from todos WHERE id=1然后使用 checkCanSee(resultFromDatabase) 验证授权.

但是，假设我的 todos表现在包含来自多个用户的 100,000 个待办事项，纯粹在业务层执行授权变得不切实际，因为我需要获取每个待办事项，使用共享授权逻辑过滤结果，然后将其切片以执行分页。

我错误地认为解决这个问题的唯一方法是让授权逻辑驻留在持久层本身中吗？

Answer 1

我认为 Dan 演讲的要点之一是使用 GraphQL 处理授权的方式与典型的 REST 端点不同。

在 REST 中，每个资源通常都与一个端点相关联。当向该端点发出请求时，在处理请求之前检查请求者是否获得授权是有意义的。使用 GraphQL，我们可能会在同一个请求中获取多个资源，因此不再需要这种行为。正如丹所说:

We don’t want to completely blow up the request if you can’t see one of [the requested resources].

因此，GraphQL 的首选方法是实现某种 每个节点 授权机制，并且只返回请求者有权查看的资源。这正是谈话中的例子所展示的——一种方法。

如果您将待办事项存储在 SQL 数据库表中，那么您的代码只需执行类似 SELECT * from todos WHERE creator_id=${viewer.id} 的查询就非常有意义。并省略使用类似 checkCanSee 的函数共。

类似地，您可以使用限制偏移、游标等将分页直接添加到您的查询中。 是的，既然您现在让您的数据库完成繁重的工作，您可以说我们已经进入了持久层。但是，接受请求、清理输入、构建适当的查询并以 GraphQL 可以使用的形式返回结果仍然取决于您的业务逻辑。

我不能代表 Dan，但我想他的意图并不是暗示这是实现节点授权的唯一(甚至是最佳)方式。我认为更重要的是，例如，如果您正在获取:

{
  header
  todos  {
    description
  }
  quoteOfTheDay
}

即使未经授权的客户端仍然应该从服务器获得响应，然后它可以用来为最终用户呈现页面(即使该响应包含一个空的待办事项数组)。