结构化GraphQL类型

Question

尝试扩展我的API以包括GraphQL端点时遇到问题。我正在处理的应用程序是带有的论坛Messages。一条消息可以包含类型的注释Message。如果消息是注释，则其父类型为Message。简化后，该架构如下所示：

type Message {
  id: String
  content: String
  comments: [Message]
  parent: Message
}

type RootQuery {
  message(id: String): Message
  messages: [Message]
}

这种模式的问题在于它允许这样的查询：

{
  messages {
    comments {
      parent {
        comments {
          parent {
            comments {
              parent {
                id
                content       
              }
            }       
          }
        }   
      }
    }
  }
}

请记住，我可能希望允许任意深度的注释嵌套。在这种情况下，应允许以下查询：

{
  messages {
    comments {
      comments {
        comments {
          id
          content
        }
      }
    }
  }
}

因此，我的问题是：我应该向不知道其父级的API引入一种新类型-Comment-吗？还是有其他方法可以限制这种不良行为？

另外，使用注释类型是否会禁止我fragment messageFields on Message在查询中使用语法？也许是时候将接口引入架构了？

如果我引入类型为Comment的解决方案的建议（我还没有尝试过）：

interface Message {
  id: String
  content: String
  comments: [Message]
}

type DefaultMessage : Message {
  id: String
  content: String
  comments: [Comment]
  parent: Message
}

type Comment : Message {
  id: String
  content: String
  comments: [Message]
}

type RootQuery {
  message(id: String): Message
  messages: [Message]
}

Answer 1

如果消息是评论，则它具有消息类型的父级。

看起来parent应该是场下type Comment，不是DefaultMessage。但这仍然无法阻止parent - comments - parent查询，但如果您出于 DDOS 原因担心这一点，那么即使使用 REST API，也有许多其他类型的请求难以计算，您应该采取其他措施来检测此类攻击。

递归节点

但是，您通过嵌套评论提出了一个非常有趣的问题。您如何知道需要comment在查询中嵌套多少次才能获得所有嵌套响应？我认为目前 GraphQL 无法指定递归对象。

我可能会通过从最后一条评论开始逐一获取每个嵌套评论（或一次 X 级）来绕过此限制node

{
  messages {
    comments {
      id
      content
    }
  }
}

其次是

{
  node(commendId) {
    comment {
      id
      content
    }
  }
}