我应该制作自己的graphql样式api，但只能使用续集吗？

Question

语境

嗨！ 我做了类似graphql的东西，但仅使用了Sequelize。 我的意思是，Sequelize查询选项是JSON对象，因此，客户端可以直接发送选项（使用正确的清理方法）。

我做了什么

出于好奇，我建立了它，并且效果很好。 现在我的疑问是：那有多糟？

这是使用此API的客户端的示例

    const res = await http.post(APIs.FINDER, {
      model: 'User',
      options: {
        where: {
          id: someId
        },
        attributes: ['name', 'active']
      },
      include: [
          {
            as: 'zone',
            attributes: ['name']
          }
      ],
      order: [['createdAt', 'DESC']]
    });

好吧？

消毒/约束

关于消毒，我必须：

• 检查包含项是否具有已知限制，例如：嵌套的包含项不超过10个
• 检查参数是否不是SQL字符串或其他技巧（Sequelize对此有所注意）
• 不允许Sequelize函数，仅允许简单查询

问题

考虑到这一点，我认为这可以用于生产中。

• 我是否错过了一些可以在生产使用中拒绝这个想法的东西？ （安全/使用/等）
• graphql是否具有一些使我更喜欢此自定义解决方案的特定功能？
• 您会在生产环境中使用它吗？ 我无法想象为什么不

Answer 1

我对以下问题的看法：

1. 我不推荐这种风格的API。 它将使您的后端实现向公众公开，这使您难以处理所有安全条件，更不用说业务逻辑和授权了。 另外，由于行为与sequ​​elize程序包紧密相关，因此很难提高性能。

2. 您可以考虑这篇文章： GraphQL突变设计：贫血突变 。 一个好的GraphQL API应该由领域和需求驱动，而不是由数据驱动。

3. 没有！ 我在处理这种api样式时遇到了困难。

---

实际上，这不是一个好主意。 如果您正在组织一个单人的全栈项目，乍一看它可能看起来很快，但是开发成本会飞涨，直到您不能继续前进为止。 如果您是一个小组，则可能会注意到客户端与服务器端紧密相连，这对开发非常不利。

在客户端，它只需要有限的一组api，而不需要无限的api。

在服务器端，您什么也做不了，只能将数据移交给序列化，这很难提高性能，添加逻辑层以及将其他数据库系统（例如弹性搜索）引入您的代码库。

在设计API时，可以考虑称为DDD的域驱动设计 。 与使用GET { type: 'User", where: ..., include: ..., order: ..., limit: 10 }相比，首选使用GET Friends?limit=10 api GET { type: 'User", where: ..., include: ..., order: ..., limit: 10 }

顺便说一句，GraphQL不仅是一种查询语言，本质上还是一个薄API层（ ref ）。 因此，请勿将其用作JSON数据库，而应将其视为关注业务需求的API。

例如，这是一个用户模型：

{
  "User": {
    "id": 1,
    "name": "Mary",
    "age": 20,
    "friendIds": [2, 3, 4] 
  }
}

但是在GraphQL中，根据您的需要，它可能变为：

type User {
  id: ID
  name: String
  friends: [User]
  friendCount: Int
  friendsOverAge18: [User]
}

您可以阅读有关如何设计GraphQL API的精彩文章： Shopify / graphql-design-tutorial