我们有一个graphql服务器(不是用javascript编写)服务于分页的对象列表.我们试图遵循继电器规范,但我们遇到了一个可以使用澄清的有趣案例.
具体来说:是否允许游标依赖连接的其他输入？与https://github.com/graphql/graphql-relay-js/issues/20类似,我们的连接采用sort_key参数来确定返回列表的排序顺序.根据指定的排序顺序,对象的边可能返回不同的游标值(因为服务器在每种情况下都需要不同的信息来确定下一个对象).但是,仔细阅读https://facebook.github.io/relay/docs/guides-mutations.html#range-add表明这是不允许的; 返回新创建的边的突变必须返回一个光标,该光标可以普遍应用于可能出现该边的所有可能列表？facebook如何解决这个问题？
在graphql API之上构建新应用程序时,我们遇到了以下问题:
我们有一个带有输入字段的变异,其类型是具有自己的验证规则的自定义标量(在这种情况下,输入是格式良好的电子邮件地址).
在客户端,应用程序的用户填写了一堆字段并点击提交.目前,电子邮件地址的验证由GraphQL层处理,如果失败并出现顶级错误,则中止该突变.所有其他字段的验证由变异处理,返回变异有效负载中的应用级错误.在这种情况下的其他验证不能直接在模式中表示,因为它们涉及相互依赖的字段.
这种行为对客户来说真的没有用处:它现在必须知道两个可能位置的错误(顶级graphql错误,以及突变有效负载中的应用程序错误)以及两种可能的格式.这也意味着在修复所有架构级问题之前,不会报告其Graphitive架构中未表示格式错误的其他格式错误的字段,从而迫使用户经历多轮"修复错误,点击提交,得到另一个错误".
这个问题的标准解决方案是什么？在客户端上进行验证(在这种情况下非常复杂)？弱化模式以便在应用程序层对所有相关验证进行分组？
我们有一个不是用javascript编写的graphql服务器,我们试图遵循中继规范.startCursor并endCursor出现在一些例子中,但没有出现在任何官方文件中; 根据我对https://github.com/facebook/relay/issues/372的解读,这些字段基本上已被弃用,但它们确实会出现在某些代码中.我们必须实施它们:
https://facebook.github.io/relay/graphql/objectidentification.htm非常清楚Node它的行为和行为,但它没有指定哪些对象必须实现它,或者如果你的对象没有它的后果是什么实现它.是否有一组不起作用的功能？这些物体完全被忽略了吗？并非现有规范中的所有对象(例如pageInfo)都实现它,因此它显然不是普遍要求的,但pageInfo在某种程度上是一种特殊情况.