GraphQL和gRPC
GraphQL（图形查询语言）是一种强大的查询语言，它使Facebook和Github之类的大型组织能够暴露大量数据。gRPC是最初由Google开发的开源远程过程调用（RPC）系统。尽管这些技术生活在截然不同的空间中，但它们可以协同工作并完美互补。
多年来，Roy Fielding的REST（代表状态传输）API一直是向客户端应用程序公开数据的主要工具。就像任何老开发人员所知道的那样，如果您坚持使用这些API设计实践，那么您将比临时API协议以及冗长的SOAP和CORBA领先几英里。关键的改进包括：统一的界面，无状态的交互，客户端和服务器之间的清晰边界以及一种简单的缓存方式。
但是，在撰写本文时，这种类型的API已有17年历史，并且正在显示其年龄。特别是由于它们难以自定义，版本化和维护。
事态
如今，在为客户端应用程序公开数据时，我们遵循一组明确定义的步骤。为了创建数据并公开对象之间的简单关系，我们甚至可以使用CRUD原理使过程自动化。
CRUD（代表创建，读取，更新和删除）是一种与数据库进行原子交互的方式，当与REST结合使用时，它将利用HTTP谓词；POST用于创建，GET用于读取，PATCH用于更新，DELETE用于删除。
当您的应用程序基本上将电子表格放在网络上（一种非常高需求的应用程序类型，在可预见的将来绝不会消失）时，CRUD是必经之路。您可以以惊人的速度移动，主要是通过使用自动化工具和“可靠而真实的”开发技术。
尽管有其优势，但仍有一些决定性的弱点可以使这种范例进行或破坏任何应用程序。当处理可以最好地表示为图形的数据时，这些弱点变得更加明显。例如社交网络，购买建议和IT运营数据。
一个特定的弱点与资源受限的环境有关，例如在慢速移动网络上运行的应用程序。在这种情况下，有一些选择，第一种是使用传统方法，根据这种方法，您可以使请求保持原子状态，并对每个递归定义进行一个请求。如果您没有太多的递归定义，那不是一个大问题，但是如果您不对其进行检查，则请求会迅速堆积。
递归资源（橙色）和请求（绿色）的模型，请注意不必要的请求
第二种选择是为应用程序中的每个功能开发一个自定义端点，实现每个功能所需的递归级别，并在此过程中修剪不必要的数据。
第三种选择是迁移到这种类型的数据的更合适的表示形式，即图形数据库。由于服务可用性问题或开发团队的技能要求，即使可能，这种努力也可能不可行。
这些方法可能浪费资源；开发时间或最终用户资源。
现状的另一个要素是HTTP / 1.1和文本作为基于微服务的系统资源之间的传输通道的普遍使用。
微服务的模型，使用HTTP进行内部通信
既快速又容易使用；但是，在大型的基于微服务的系统上，请求的数量充其量随服务的数量线性增加。当您使用有点浪费的协议完全控制系统时，这不是理想的选择。
您可以通过使用压缩来减轻这种浪费，然后将REST事务的两个参与者的CPU时间用于网络流量。
输入GraphQL
GraphQL是Facebook对递归资源问题的解答，而无需将所有数据层都迁移到图形数据库。您可以将查询直接映射到图形数据库，也可以通过高级抽象来将其映射为传统SQL数据库的功能。
GraphQL的所有实现的设计方式都使您可以直接对其访问数据库，尽管如此，它还可以通过现有端点访问数据。
在JavaScript实现中，我们有一个称为解析器的概念。这些有助于程序员定义如何检索数据。可以对数据进行预处理，选择要发送的部件或直接发送。
输入gRPC
gRPC是Google试图结束HTTP / 1.1统治并替换为性能更高的标准的尝试。通过使用协议缓冲区标准并使用HTTP / 2的二进制编码消息的优点。
要开始以您选择的语言实现gRPC并进一步了解此问题，请务必参阅出色的文档。
GraphQL和gRPC似乎是天作之合，因为两者都试图缓解跨网络传输大量消息的问题，并且由于GraphQL使用高级方法而gRPC使用低级方法，因此可以无缝地一起使用它们。
使用GraphQL作为智能端点，使用gRPC与内部服务进行通信
通过使用GraphQL公开数据，客户端可以精确地指定所需的数据，并且通过使用gRPC进行内部通信，您正在减少，甚至减少了应用程序的资源和请求占用空间。
题库