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

我想知道如何在编写应用程序时将传输层(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解析器上下文参数进行授权,依此类推.

我想到的时间越长,我就越确信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用于业务逻辑？

解决方法

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

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来处理业务逻辑,但是,如果对您来说更容易,您可以使用函数式编程接口来构建业务逻辑.

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