2. GraphQL 对付前端开拓者更切合人机工程学
功效就是界面的利用方法就少了许多，它们只为你提供所需的数据，不需要不绝更新以支持外部开拓者的新用例。
}
“name”: “Root”,
{ “name”: “id” }
2.当前模子效率低下；
name
区块链的焦点是不行变值的仅附加数据布局：一系列区块构成的链。尽量每个区块都是不行变的，但我们可以通过使变量（譬喻帐户余额或智能合约状态）的代价因区块而异来模仿可变性。通过这种模式，我们可以自由得到可审计性，这意味着我们可以看到任何变量随时间变革的环境，从而答允外部流程安心地直接依赖于此数据。
}
基于区块链构建的 dApp，GraphQL 会胜过 SQL 的几个主要原因：
Facebook 存心这样做是为了抹杀竞争，而 Twitter 则是为了更有效地操作其数据赢利。InfoWorld 资深作家 Serdar Yegulalp 谈到了 Twitter 的故事，简要论述了开拓专有 API 的风险：”称它为 API 经济的职业危害之一：对单个实体的依赖越遍及和多面化（无论是作为数据源，阐明层照旧基本架构），从地毯中抽出地毯越容易在你的脚下。“
{ “name”: “name” },
然后挪用：
query {
/api/v2/organizations/7
尽量区块链的热度要大得多，但我将首先先容内容寻址存储，因为它是更简朴更基本的观念。这个想法是：对付任何数据片断（数据库中的实体、文件系统中的文件、CDN 上的 Blob），你如何引用这些数据？是否给它提供一个任意的 ID、URL 或名称，按照你的询问方法，它可以在差异的时间引用差异的数据……照旧给它一个独一的 ID，该 ID 可以永远永久地理会为特定值，无论它是从在你本身的当地文件系统，在长途处事器上，照旧从另一个星球提供？
这些果真 API 的刚性需要大量特另外工程事情来办理，这就激发了下一个问题。
1. API 僵化且维护本钱高
另一方面，GraphQL 成果强大，足以在单个查询中表达应用所需的所有数据。无论你需要几多数据，利用 GraphQL 都不需要举办多个网络挪用。有时这称为办理获取不敷问题。另外，你只需要得到所需简直切数据，而不需要得到更大都据，从而办理了太过提取的问题。
}
{
然而，这一 SQL 查询布满了 Postgres 数据库的供给商特定的参数。MySQL 数据库的等效查询将有所差异。别的，尽量上述查询很容易以纯文本形式阅读，但发送查询和吸收响应却需要非凡的东西：特定供给商的 CLI 客户端或跨供给商的桌面 GUI，可以领略特定供给商的 SQL 气势气魄，有线协议，ODBC 或以上各项的组合。
操作和存储网络作为数据互操纵性层
译者： 陈俊
3. GraphQL 旨在跨信任界线利用
3.专有 API 导致数据把持。
“name”: “User”,
并且，GraphQL 查询的响应是一个 JSON 工具，它完全反应了请求的形状。
作者： Brandon Ramirez
O’Brien 和 Hucka 描写了一种常见现象：要么在这些数据管道中如何将中间功效存储在私有数据库中，要么由于要让这些数据可果真利用而需要举办的工程事情而被完全裁减。功效是反复劳动的两个维度：在数据管道内，以及由孤独的团队和组织建设的各类数据管道之间。
数十年来，市面上独一被遍及利用的数据库是 SQL 数据库，它仍然是大大都组织，软件应用和机构的焦点。然而，跟着区块链的到来，干系数据库终于有了替代选项，并且我谈论的不可是 NoSQL 举动带来的增量改造。我们正处于所谓去中心化网络或 Web3 等新典型的风口浪尖，个中数据（而非专有 API）是互操纵性的基本。在这篇文章，我将表明为什么会产生这种转变，以及 GraphQL 查询语言如何被奇特地定位以支持这个新的数据互操纵时代。
[1] GraphQL Will Power the Decentralized Web: https://medium.com/graphprotocol/graphql-will-power-the-decentralized-web-d7443a69c69a
进入区块链和内容寻址存储
这并不是最糟糕的工作，可是可以说它不如 GraphQL 查询那么直观简朴。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
