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？我想到的唯一缺点是，如果我想从＆＃34;内部＆＃34;中调用一些业务逻辑方法。我的应用程序我不得不用GraphQL查询调用它感觉有点尴尬 - 但我想这可以通过将GraphQL查询编写为普通对象（json）并转换为GraphQL来解决...

你们觉得怎么样？您是否将GraphQL用于业务逻辑？

Answer 1

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

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

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

有些人最终使用ORM来处理业务逻辑，但是，如果您更方便，则可以使用功能性编程接口来构造业务逻辑。

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

为什么不将GraphQL用作业务逻辑层？

1 个答案: