Answers:
缺点：
但是，这些远远不止这些：
graphql-spring-boot-starter和graphql-java-tools上手。在.graphqls资源中创建架构并创建Resolver类，您就完成了。要启动并运行一个有效的测试示例，大约需要10分钟。
对于考虑使用GraphQL的任何人，我已经发现了一些重要的问题，到目前为止，要点是：
不定深度查询：GraphQL无法按不定深度查询，因此，如果您有一棵树并想返回一个不知道深度的分支，则必须进行一些分页。
特定的响应结构：在GraphQL中，响应与查询的形状匹配，因此，如果您需要以非常特定的结构进行响应，则必须添加一个转换层以重新调整响应的形状。
网络级缓存：由于GraphQL通常用于HTTP（单个端点中的POST）上，因此网络级缓存变得很困难。解决此问题的一种方法是使用持久查询。
处理文件上传：GraphQL规范中没有关于文件上传的内容，并且变体不接受参数中的文件。为了解决这个问题，您可以使用其他类型的API（例如REST）上传文件，并将上传文件的URL传递给GraphQL突变，或者将文件注入执行上下文中，以便将文件包含在resolver函数中。
不可预测的执行：GraphQL的本质是您可以查询组合所需的任何字段，但是这种灵活性并非免费的。最好了解一些问题，例如性能和N + 1查询。
超级简单的API：如果您拥有公开一个非常简单的API的服务，则GraphQL只会增加额外的复杂性，因此简单的REST API可能会更好。
我在graphQL上看到的最大问题是，如果您正在使用关系数据库，那就是joins。
您可以允许/禁止一些字段的事实使联接变得很简单（不简单）。这导致额外的查询。
同样，graphql中的嵌套查询会导致循环查询，并且可能使服务器崩溃。必须格外小心。
限制呼叫速率变得很困难，因为现在用户可以在一个呼叫中触发多个查询。
提示：在使用javascript / node的情况下，使用facebook的dataloader减少查询数量
cost给请求。如果使用预定义查询（客户端仅发送ID），这也不是问题。
每年它都在变得越来越好，就目前而言，GraphQL 社区正在增长，因此，针对许多问题的解决方案更多了，这些问题在以前的其他答案中都得到了强调。但是要承认将所有资源投入GraphQL仍然使公司陷入困境，我想列出一些问题和解决方案，然后是未解决的问题和解决方案。
但是还有更多情况可以算作不利条件：
综上所述，GraphQL只是实现特定目标的工具，并确保它不是所有问题的灵丹妙药，当然也不是REST的替代品。
拥有一个端点并公开所有数据确实很棒。我发现GraphQL需要考虑以下几点：
此外，在实施后应该考虑专业人士：
实施后即可使用参数和自定义顺序轻松添加条件
使用大量自定义过滤器，并摆脱所有需要创建的操作，例如，用户可以将id，name等作为参数并执行过滤。另外，过滤器也可以应用于用户中的组。