Question

我已经阅读了有关组织graphql查询的不同方法。大多数似乎都针对每个不同的动作显示查询/变异。

即

@Query('getComment')
async getComment() {
  ...
  return comment;
}
@Query('getComments')
async getComments() {
  ...
  return comments;
}
@Query('getCommentByID')
async getCommentById(id) {
  ...
  return comment;
}

添加所有不同的排列后，我有很多查询和变化。

其他资料来源建议尽量减少图表的入口点。经过一些实验，我得到了：

// schema
type Query {
  comment: CommentActions
}

type CommentActions {
  getCommentByID(id: ID!): Comment
  getAllComments(): [Comment]
  getComments(): [Comment]
    ...
    // etc
}

然后在我的解析器中（此示例在NestJS / apollo中）

@Query('comment')
async getComment(): Promise < CommentActions > {
  return new CommentActions();
}

@ResolveProperty('getAllComments')
async getAllComments(@Parent() comment) {
  // ...
  return comments;
}

@ResolveProperty('getCommentById')
async getAllComments(@Parent() comment, @Args('id')) {
  // ...
  return comment;
}
// etc

查询变体实质上已移至字段解析器。该POC在技术上可以正常工作（查询图形没有问题）。

查询示例如下：

query {
   comment {
    getAllComments {
      id
    }
  }
}

我之所以这样，是因为这意味着在已发布的图形模式（例如，在gql操场上）中，可以更轻松地对事物进行分组，并且每个实体只有一个入口点。

这种方法是否有缺陷？这是“确定”的，但不是一种非常“ graphql”的处理方式：我担心我无意间将REST之类的模型强加到不合适的地方。

是否存在随着架构变得更加复杂而变得更加困难和/或不可能的问题或其他任务？

非常感谢任何/所有对替代结构的反馈，见解或建议。

graphql组织：将“操作”放入嵌套类型以减少/分组入口点？

0 个答案: