在过去的几个月中，我一直在努力改善REST API的性能。 该API不拥有任何数据库，并且基本上依赖于其他服务来为其提供所需的信息。 因此，我们必须探索可以尽快处理或收集信息的方法。

　　在此分析过程中，我探讨了GraphQL帮助我们完成任务的可能性。 围绕GraphQL解决所有问题的流行语很多，但我不想因为这个趋势如此流行而流行。 因此，我围绕它进行了一些研究和原型设计，并将其与其余的端点实现进行了比较，以找出一些利弊。

　　为什么选择GraphQL为客户提供更多动力

　　这是GraphQL最重要的好处，即客户端或前端可以完全控制数据需求。 GraphQL不是后端将数据推送到客户端，而是允许客户端请求它。 结果，服务器将仅处理所需的内容，并仅返回所需内容。 它节省了CPU，网络调用，网络带宽。

　　例如，我正在使用的权限API具有每个视图所需的一组不同的权限。 根据视图的复杂程度，它们的权限从1到10不等。 因此GraphQL完全适合这里。 代替服务器评估所有权限并回馈用户以在其中进行选择。 GQL将允许查看者询问所需的任何许可，服务器将仅评估并提供那些许可。 超过50％的视图很简单，因此它们将变得更快。

　　减少Rest端点爆炸/复杂性

　　处理上述情况的另一种方法是基于每个视图提供多个端点。 或者，您可以向客户端提供过滤器，以在查询参数中传递权限名称。 老实说，我不喜欢在看到这种情况后在API中实现这些条件检查，您可以在GraphQL中立即使用它，因为它会使您的代码变得有条件且混乱。

　　模式使您的域模型非常清晰

　　制作GraphQL模式时，需要遍历图时在实体之间建立非常清晰的关系。 在静态API中，将所有内容都放在同一个API中非常容易。 我已经看到太多的API，其中包含不合适的内容，以节省来自客户端的额外调用。 从API很难理解它。 GraphQL模式使客户端可以很清楚地在哪里找到他们要查找的内容。

　　共享架构可以帮助所有人

　　我们努力寻找可以为我们提供所有正确数据的端点有几次。 大概总是。 使用GraphQL模式，任何人都可以很容易地查看模式并弄清楚。

　　启用并行处理

　　在GraphQL中，每种类型/字段都有一个提供程序来获取数据。 可以并行获取相同级别的字段。 例如，如果一个用户对象并且您想同时获取他们的工作详细信息和健康历史记录，则GraphQL可以并行执行数据获取程序以对其进行优化。 就我而言，我必须提取十个权限，我可以通过自己的线程执行器来执行此操作，但是使用GraphQL可以立即使用。

　　为什么不用GraphQLREST端点是简单的CRUD

　　REST端点非常简单。 例如，通过其ID获取用户，则无需过滤数据。 然后GQL可能成为负担，因为其余的API可以更快地启动和运行。 当您的客户端需要多种形状的数据时，GraphQL超级有用。

　　失败的影响很大。

　　随着越来越多的人开始使用GraphQL，架构会很自然地扩展，以便人们可以轻松地找到数据。 由于有这么多人在架构后面工作，任何人的变更都会影响很多其他人。

　　您需要对GraphQL非常小心。 有了REST API，只有该API及其最终用户会受到影响。

　　处理n + 1种情况的性能很复杂。

　　使用GraphQL，如果您需要查找有关列表或记录集合的信息，则处理起来会很棘手。 例如，如果您想获取包含其地址的用户列表的详细信息，则它将执行n + 1个查询。 一个用于用户列表，然后n查询每个用户的地址。

　　现在它会严重影响性能，因此必须非常小心地处理它。

　　完全掌控自己的工作方式和做事方式

　　尽管GraphQL为您提供了我们上面已经看到的许多现成的东西，但是使用REST API，您确实可以很好地控制请求的处理。 无论是批量数据库请求，并行化，利用线程局部语言，还是使用Rest API都更易于管理。

　　摘要

　　我认为随着现代应用程序的复杂性和需求，使用GraphQL可以为后端和前端的开发人员提供相当大的灵活性。 虽然可能需要一些时间来学习和开始使用GraphQL，但似乎值得付出努力。