… 我最大的抱怨是似乎没有一种方法可以查询所有字段。我知道这是有意为之的，也是GraphQL的初衷。但服务器端应该支持某种方式来实现这一点。也许近年来他们已经做到了，我不清楚。但我的经验是在实施阶段，客户端不断添加我之前不知道的新字段，然后我不得不不断向他们询问这些字段，因为我以为我漏掉了数据。如果我能直接查询所有字段，然后查看返回的内容，再从中挑选我需要的部分，那就太好了。GraphQL似乎只有在所有内容都基本定义好，并且你处于项目最终阶段时才有意义。经过多年的经验后，我发现这种情况很少见。这是一项酷的技术吗？当然，但除了在数据量极大的情况下，并且只有当客户端返回特定字段有意义时，它才实际有用。尽管我认为即使在这些极端情况下，95%的情况下你只需编写一个返回适合查询字段的REST端点就可以了。
源讨论在六年之后，我已经厌倦了GraphQL原帖 698 条评论 · 导入时统计把你的经验，加入这段讨论。
我认为你对它适合明确的场景的说法是对的。但我也同意，一个常规的端点来获取特定数据在大多数情况下是完全可接受的。我不太清楚有多少情况下的GraphQL的灵活性比它对团队的要求更有用或更重要。 我曾在一个团队工作，其中我们三人都是有超过二十年软件开发经验的，但即便如此，我们还是请了一位顾问来帮助我们对GraphQL的实现和持续策略进行合理性检查。 我们基本上走在正确的轨道上。我们遇到的困难只是……正常的。 在这一点上，我真的失去了动力。在此之前，我被一种感觉所激励，即有些东西还没弄明白。后来发现我其实完全理解GraphQL，但通常开发体验很差，工具晦涩难懂，查询也很难，这让我感到很沮丧。 最糟糕的是突变（mutations）。 写...…
完整原文我肯定不是GraphQL高手，但我认为你所描述的情况可以通过内省调用来实现，当兄弟评论提到模式时，它暗示了这一点，但我是在说这其实是一个运行时调用，就像其他任何调用一样，因此不需要“阅读”。我认为内省功能是可选的，因为一些公司认为它是一个信息泄露的途径，但对于开发/测试环境，我认为这是一个完全可以接受的权衡。 https://graphql.org/learn/introspection/
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。