为什么不将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

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

我想到的唯一缺点是，如果我想从我的应用程序的“内部”调用一些业务逻辑方法，我将不得不使用 GraphQL 查询调用它，这感觉有点尴尬

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

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

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