作者:飞儿gxj_505 | 来源:互联网 | 2023-02-01 22:54
我想知道如何在编写应用程序时将传输层(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用于业务逻辑?