关于javascript:爱-GraphQL-胜过-REST

30次阅读

共计 2871 个字符，预计需要花费 8 分钟才能阅读完成。

自从 Facebook 开源 GraphQL 以来，GraphQL 越来越受欢迎，直到明天它曾经是简直无处不在。到底是什么使它如此受欢迎？它与 REST 架构设计标准的区别是什么？它会齐全地取代 REST API 吗？上面是我对 GraphQL 的一些思考。

当我第一次学习 GraphQL 时，我对它无所不知。在我学习 GraphQL 的过程中，甚至在开始学习 GraphQL 之前我就意识到了同样的想法，我将要学习的是一个与 Rest API 齐全不同的货色：

GraphQL 是一个独立存在的，没有应用咱们相熟的 REST API 内容。

这个想法有点不切实际和滑稽，但这却正是 GraphQL 给从未接触过它的人所显露出来的样子。

如果要我用最简略的术语来定义 GraphQL，那么我会说它是一个标准，是应用咱们现有的网络技术十分厉害的一种形式。GraphQL queries 实质是一个简略的链接到 API 端的 HTTP POST 申请。是的，它被设计成须要用一个蕴含 GraphQL queries 的 HTTP POST 申请去和后端通信。让咱们通过疾速构建 GraphQL 服务器来查看示例。

为了简略起见，我将应用 Nodejs 构建。因为 GraphQL 自身就有一个运行上下文，所以构建 API 所用的语言无关紧要。接下来让咱们疾速装置依赖项：

yarn add apollo-server moment

并构建一个简略的 GraphQL API

const {ApolloServer, gql} = require("apollo-server");
const moment = require("moment");

const server = new ApolloServer({
  resolvers: {
    Query: {getDateTime: () => ({date: moment().format("MMM DD YYYY"),
        isoString: new Date().toISOString(),
      }),
    },
  },
  typeDefs: gql`
    type dateTime {
      date: String!
      isoString: String!
    }
    type Query {getDateTime: dateTime}
  `,
});

server
  .listen(4000)
  .then(() =>
    console.log(`Application worker ${process.pid} is running a server at http://localhost:4000`
    )
  );

执行一个查问

是的，如果您已经接触过 GraphQL 训练场就晓得到我下面所说的是完全正确的。一个 GraphQL 客户端（包含 GraphQL 训练场）应用与下面相似的主体向指定的 API 端点 / 通道发送 POST 申请。GraphQL 运行上下文可能晓得如何解决申请，因为它对将要获取和返回的数据的 schema 有感知。

然而，当您想要返回类型定义中未指定值时，这通常会导致意想不到的行为，因为 GraphQL 会主动地尝试对值进行类型转换，并在不起作用时解体。

阐明 —— 对 GraphQL API 的每个申请都会被归类为查问，包含变更，订阅和查问。

不，远远不止于此，GraphQL 为您的 API（尤其是客户端）带来了更多的可能，GraphQL 通过反对仅返回 query 中的特定字段，达到仅查问所需的数据而疏忽其余不须要的数据的成果，从而减小了传输数据的大小，带宽和提早。让咱们批改一下下面的代码：

const {ApolloServer, gql} = require("apollo-server");
const moment = require("moment");

const server = new ApolloServer({
  resolvers: {
    Query: {getDateTime: () => ({date: moment().format("MMM DD YYYY"),
        isoString: new Date().toISOString(),
        localString: new Date().toLocaleString(),
      }),
    },
  },
  typeDefs: gql`
    type dateTime {
      date: String!
      isoString: String!
      localString: String!
    }
    type Query {getDateTime: dateTime}
  `,
});

server
  .listen(4000)
  .then(() =>
    console.log(`Application worker ${process.pid} is running a server at http://localhost:4000`
    )
  );

咱们在 dateTime 类型中增加了另一个字段，这次咱们不想查问其余两个字段。这真的非常简单，咱们要做的就是在收回如下申请时指定咱们感兴趣的字段：

对于小型利用，这个成果可能不会太显著。然而对于大型的利用来说，您总会想要一个最优的解决方案。因为仅查问须要的字段这个想法自身就很棒，因而这个想法始终都是传统 REST 架构中的一部分，并且为检索某些特定数据的解决方案指明了路线。这对于小型应用程序甚至在实践上都没有问题，然而随着应用程序大小的减少（比方 Facebook），数据传输的连接线会变得越来越简单，最终您将不得不从新设计整个零碎去应用 GraphQL 之类的解决方案，或者最终将导致从新写一个 GraphQL。

GraphQL 还附带了许多很酷的性能（比方“订阅”），如果有机会我会写一篇文章谈一谈 GraphQL 是否比传统的 REST API 更好。

我批准 GraphQL 是更好的 REST 版本，它是 REST 的弱小替代品，但它不会在明天或不久的未来齐全取代 API。造成这种状况的起因有两个。

对于小型应用程序，REST API 简直能够实现 GraphQL API 的所有工作。

因为 GraphQL 通过容许客户端仅查问所需字段来为客户端带来更多功能。然而，如果客户端的申请嵌套大量字段，并且须要波及多个资源（例如从文件系统或数据库读取），那么这个弱小性能将会就义掉服务端的性能。而且，假如须要反对数亿个这样的申请，如果您的服务器无奈进行疾速扩容的话，那么这将会导致服务器的资源被耗尽。

以上就是为什么在 企业界，GraphQL API 会与 REST API 联合来应用的起因。

原文地址：Loving GraphQL More than REST

原文作者：Saurav Singh

译文出自：掘金翻译打算

本文永恒链接：https://github.com/xitu/gold-miner/blob/master/article/2020/loving-graphql-more-than-rest.md

译者：NieZhuZhu（弹铁蛋同学）

校对者：regon-cao、司徒公子

正文完