消除对GraphQL的困惑
> Image by TeeFarm from Pixabay
因此，请告诉我为什么我要与团队中的一名工程师就GraphQL的好处进行辩论，而他试图通过说："您只喜欢它是因为它对前端开发人员是有好处的"。
老实说，我有点不高兴，因为我认为这是我职业生涯中的几次，其中一位只知道服务器端开发的工程师因为我喜欢构建用户界面而拒绝了我的意见。
经过一番思考，我意识到他是对的。 GraphQL对客户端确实非常有用。 对于服务器端来说也很棒，但这不是我们讨论的重点。
当比较GraphQL和REST时，可以观察到的是典型的REST服务针对服务器进行了优化，而GraphQL服务针对客户端和服务器端开发进行了优化。
顾名思义，GraphQL服务旨在使客户满意和高效。
这不是我第一次进行这样的讨论，所以我想继续讨论我在GraphQL传福音之旅中遇到的一些关于GraphQL的误解。
1.您正在公开整个数据库
"但是William，借助GraphQL，您正在将整个数据库公开给客户以执行他们想要的任何事情。"
您没有公开整个数据库。 我曾与讽刺地描述GraphQL来公开整个数据库并允许客户从数据库中查询所需内容的人们进行过交谈。
通常将其描述为一个缺点，使GraphQL基本上是您前端的数据库连接器。 此定义存在一些问题。
您可以在没有数据库的情况下使用GraphQL服务
正如GraphQL服务不必基于Graph数据库一样，您可以拥有不带数据库的GraphQL服务。 它可以用于执行计算和处理的服务或代理其他服务。
您设计自己的模式
由于您设计自己的GraphQL模式，因此该服务仅会公开您希望通过模式访问的内容。
您可以限制用户查询的复杂性
由于GraphQL查询可以嵌套和批处理，因此可以使用一些工具对查询的复杂性施加一些限制。
例如，诸如GraphQL查询复杂度之类的工具可通过限制查询的复杂度并防止嵌套过多的查询来帮助防止不良行为者。
2. GraphQL不安全
GraphQL服务与您提供的服务一样安全。 需要了解的一件事是GraphQL只是应用程序的一部分； 查询层。
这是GraphQL的创建者在与Airbnb等其他公司交谈以了解GraphQL如何在野外使用时重申的一件事。
到Facebook开始使用GraphQL时，他们已经拥有了GraphQL可以容纳的完善的安全性和数据获取层，因此他们没有发现需要在GraphQL规范中强调这些内容。
他们认为在Facebook拥有的所有层和工具都是显而易见的，并可供其他开发人员和公司使用。 这使得社区很难就如何在GraphQL应用程序上处理身份验证和授权达成共识。
好消息是，我们在REST服务中热爱的许多安全方法和应用程序也可以类似的方式用于保护GraphQL服务。
这是实现安全性的几种方法（有些与我们已经为REST服务所做的非常相似）
· JSON Web令牌：只需将它们传递给标头即可，就像使用REST服务一样。
· API密钥：您可以实现自己的API密钥系统或通过API网关代理服务以保护应用程序。 Yelp的公共GraphQL API就是一个很好的例子。
· GraphQL指令：可以将GraphQL指令用作拦截器，以解决对图的各个部分强制执行访问权限的问题。 通过实现auth指令，Apollo GraphQL就是一个很好的例子。
有关使用指令强制执行访问权限的更多信息：
在上面的示例中（从Apollo GraphQL的文档复制而来），您可以看到访问使用@auth指令由用户角色控制。 禁用字段只能由ADMIN级别的用户访问，而canPost字段只能由具有REVIEWER级别角色的用户访问。
3. GraphQL仅适用于移动和Web应用程序
"如果您没有多个移动和Web客户端，则没有理由使用GraphQL。"
GraphQL最初是随着Facebook进入移动世界而诞生的。 它在前端和全栈环境中得到了广泛的采用，这使得一些企业架构师可以轻松地将其视为前端世界中的假冒趋势。
没有什么可以限制您使用GraphQL进行服务器到服务器的连接。
由于GraphQL服务的丰富开发经验，一些出色的开发人员已经为现有解决方案构建了GraphQL实现。
这里有一些例子。
· GraphQL-Kafka-Subscriptions：这是一个库，使您可以使用GraphQL订阅查询主题并将其发布到Kafka。
· GraphQL-Redis-Subscriptions：订阅Redis消息代理的接口。
· 重新加入者：来自gRPC微服务的统一GraphQL模式。
4. HTTP / 2将杀死GraphQL
哦耶。 这是一个很大的。 GraphQL的主要卖点之一是它使客户端能够在一个HTTP请求中批量和获取多个资源。 这很吸引人，因为发出HTTP请求非常昂贵。
使用HTTP / 2，可以大大降低建立HTTP连接的成本，因此该卖点的吸引力降低了。
那么，这是否意味着一旦每个人都开始使用HTTP / 2，GraphQL将变得毫无意义。 我不这么认为。 即使能够批量查询并不是人们使用和喜欢GraphQL的唯一原因。
GraphQL的整个开发人员体验都很棒。 具有类型化模式和标准语言来查询API的功能也是开发人员喜欢GraphQL的原因。 如果您想深入了解这篇文章，请查看这篇写得很好的文章。
GraphQL在HTTP2世界中仍然有意义吗？
GraphQL提供的功能远不止往返。
我认为，从长远来看，HTTP / 2实际上将帮助提高GraphQL的功能和效率，而不是消灭它。
结论
GraphQL绝对不是完美的，但我认为在改善开发人员体验以及我们如何构建产品方面，它可以提供很多帮助。
感谢您阅读本文，并让我知道您是否对此有任何想法或遗漏。 保持安全并洗手！
(本文翻译自William Kwao的文章《GraphQL Myths and Misconceptions》，参考：https://medium.com/better-programming/graphql-myths-and-misconceptions-40d2d6db9b3b)
