在很多情况下,我们有突变,其中存在我们需要变异的一对多或多对多关联,以及将关联作为分页列表暴露给查询的位置.
有一些关键要求:
不太重要:
这个问题有很多可能的解决方案:
输入类型具有单个数组输入字段,表示关联的总真实性(添加新元素,更新现有元素,删除缺少的元素,并在必要时保留顺序).
缺点:删除非常隐含.客户端必须通过关联的整个当前状态进行分页.不精细.
输入类型具有单个数组输入字段,用于更新现有元素并添加新元素(忽略缺少的元素).可以在元素上指定位置或索引值以对其重新排序.单独的突变用于删除元素.
缺点:删除在变异中自行关闭是不一致的,而所有其他操作都在父节点上.不太精细.
输入类型具有单个数组输入字段,用于更新现有元素并添加新元素(忽略缺少的元素).单独的突变用于删除和重新排序元素.
缺点:客户端无法将新元素添加到关联中的特定位置,必须添加它们,然后单独重新排序.不太精细.
与选项3类似,但输入字段仅用于更新; 单独的变异用于添加新元素.
缺点:客户必须进行多次突变才能执行复杂的更新.客户端无法使用初始关联创建父级.
父输入类型没有相关字段,所有内容都通过四个单独的突变完成,用于添加/删除/更新/重新排序.
优点:非常明确和精细,将不同的数据模型对象分开.缺点:客户必须进行多次突变才能执行复杂的更新.客户端无法使用初始关联创建父级.
输入类型有两个数组字段:一个用于更新,添加和重新排序元素(请参阅选项2),另一个用于删除.
缺点:感觉就像我们污染了父母的突变; 不精细.
与选项6类似,除了使用单独的重新排序变异而不是位置参数.
缺点:重新排序自行关闭不一致.另见选项6的缺点.
所有这些选择似乎都有缺点.选项5似乎是最明确的,但要求用户同时使用多个突变,其中操作不再是原子的.
Facebook处理这些类型突变的方式是什么?你的方式是什么?谢谢!
小智 6
所有这些方法之间肯定存在权衡,所以选择一种方法实际上取决于我想要构建的方法.
Facebook架构中最常见的情况有两个很好的约束:
Facebook上的评论是这里的典型例子.对于这样的情况,我们已经使用了Option 5并取得了巨大的成功,我可以自信地推荐它.对于评论,我们只有三个突变; commentCreate,commentEdit和commentDelete.
对于这样的情况,我们最终得到了常见的模式:
create和edit(或update)突变,突变解析的对象通常包含被修改的边缘(我使用边缘的方式与我们在分页最佳实践文档中使用边缘相同).从那个边缘,您可以轻松地获取修改后的对象...但您也可以获得可能需要的任何边缘数据.delete突变通常只返回已删除对象的ID; 如果客户端在输入中提供了ID,那么这对客户端来说是一种纯粹的便利,但如果删除输入获取了一些其他信息并且服务器将其转换为ID,则可能非常有用,在这种情况下,返回已删除的ID允许客户端知道删除了哪个对象.选项5 [...]客户端无法创建具有初始关联的父级.
我不完全确定我会这样做; 我的评论示例在这里没有一个很好的例子(因为它不存在于产品中),但假设我想发布评论并同时回复该评论,我可以想象做类似的事情:
commentCreate(input: {text:"Hello World", replies:[{text:"Reply 1"}, {text:"Reply 2"}]})
我正在重用使用的输入类型commentCreate作为接受的复数输入类型replies.
对于需要重新排序或批量操作的情况,这听起来像是你正在看的主要情况,我没有那么好的答案,而且你肯定是一个棘手的案例.我不认为我已经看到足够的例子来自信地推荐一个选项而不是另一个选项,我认为哪个选项最好可能最终取决于具体的用例.但是,要考虑的另一个选择是使用单个突变,其中输入是操作列表.因此,如果我们有一个"最喜欢的照片"列表并且我们想要进行批量更新,我们可以执行以下操作:
favoritePhotosUpdate({operations: {operation:ADD, addedId:1234}, {operation:REMOVE, addedId:5678}, {operation:UPDATE, oldId:4321, newId:8765}, {operation:SWAP, oldId:32, newId:76}
不确定这实际上是否比上面的选项更好,但它是我们过去讨论过的另一个选项(虽然我不确定我们是否已经付诸实践),所以至少值得添加到列表中.
希望这可以帮助!
| 归档时间: |
|
| 查看次数: |
877 次 |
| 最近记录: |