为啥不使用 GraphQL 作为业务逻辑层？

Posted 2023-03-08

【中文标题】为啥不使用 GraphQL 作为业务逻辑层？

【英文标题】：Why not to use GraphQL as a business logic layer?为什么不使用 GraphQL 作为业务逻辑层？

【发布时间】：2017-11-07 14:20:03

【问题描述】：

我想知道在编写应用程序时如何将传输层（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 用于业务逻辑？

【参考方案1】：

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

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

GraphQL 解析器的结构非常容易遵循，您当然应该利用这一点。

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

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