node.js - 为什么不使用 GraphQL 作为业务逻辑层呢？

Question

我想知道在编写应用程序时如何将传输层(REST API/GraphQL)与业​​务逻辑层分开。实现业务逻辑函数/方法时，例如postCreate ，它可能看起来像这样:

async function postCreate (viewer, params) {
  // validate params (don't allow additional params!)
  // authorize viewer
  // filter/modify/authorize params according to viewer role
  // perform some logic
  // filter output according to viewer role
  // return result
}

如果我想让 GraphQL 远离业务逻辑，我将不得不实现在 postCreate 中执行的所有操作自己运行(或使用第三方库)。另外如果 postCreate函数将返回嵌套数据，例如 post.author.firends那么我将不得不处理 postCreate 中复杂的图形结构函数参数。

另一方面，用 GraphQL 编写这样的函数很容易，因为有开箱即用的输入/输出验证/过滤，处理嵌套数据也很容易，可以使用 GraphQL 解析器完成授权 context参数等。

我想得越久，就越坚信 GraphQL 是编写业务逻辑的理想选择。可以通过 HTTP 公开 GrpahQL api 的事实只是一个不错的功能。如果我想制作一个标准的 REST API，我可以从 http 路由调用 GraphQL，例如:

app.post('/posts', async function (req, res, next) {
  const query = `mutation ($input: PostCreateData!) { postCreate (input: $input) { id, title } }`;
  const variables = { input: req.body };
  await graphql({ query, variables }); 
})

当然，这是一个非常简单的示例 - 在现实世界中，我们必须实现一些额外的参数，这些参数将表示用户希望在响应中接收的字段(可能是嵌套的)、正确处理错误等等。

无论如何，我的问题不是关于 REST API，因为现在 99% 的人我只写 GraphQL。问题是——为什么不在业务逻辑层使用 GraphQL？我想到的唯一缺点是，如果我想从我的应用程序的“内部”调用一些业务逻辑方法，我将不得不使用 GraphQL 查询来调用它，这感觉有点尴尬——但我想这可以通过以下方式解决将 GraphQL 查询编写为普通对象 (json) 并转换为 GraphQL...

大家怎么看？您是否将 GraphQL 用于业务逻辑？

Answer 1

您可能已经回答了自己的问题:

The only drawback that comes to my mind is that if I would like to call some business logic method from "inside" of my app I would have to call it with GraphQL query which feels little bit awkward

GraphQL 解析器的结构非常容易理解，您当然应该利用它。

有些人最终使用 ORM 来处理业务逻辑，但是，如果这对您来说更容易，您可以使用函数式编程接口(interface)来构建您的业务逻辑。

最重要的部分是您的业务逻辑无需通过 GraphQL 即可直接调用。