GraphQL 入门介绍

写在前面

       GraphQL是一种新的API标准，它提供了一种更高效、强大和灵活的数据提供方式。它是由Facebook开发和开源，目前由来自世界各地的大公司和我的维护。GraphQL本质上是一种基于api的查询语言，如今大多数应用程序都须要从服务器中获取数据，这些数据存储可能存储在数据库中，API的职责是提供与应用程序需求相匹配的存储数据的接口。有的人常常把GraphQL和数据库技术相混淆，这是一个误解，GraphQL是api的查询语言，而不是数据库。从这个意义上说，它是数据库无关的，并且能够在使用API的任何环境中有效使用，咱们能够理解为GraphQL是基于API之上的一层封装，目的是为了更好，更灵活的适用于业务的需求变化。 

GraphQL出现的历史背景       

        当提起API设计的时候，你们一般会想到SOAP，RESTful等设计方式，从2000年RESTful的理论被提出的时候，在业界引发了很大反响，由于这种设计理念更易于用户的使用，因此便很快的被你们所接受。咱们知道REST是一种从服务器公开数据的流行方式。当REST的概念被说起出来时，客户端应用程序对数据的需求相对简单，而开发的速度并无达到今天的水平。所以REST对于许多应用程序来讲是很是适合的。然而在业务愈加复杂，客户对系统的扩展性有了更高的要求时，API环境发生了巨大的变化。特别是从下面三个方面在挑战api设计的方式:

1.移动端用户的爆发式增加须要更高效的数据加载

Facebook开发GraphQL的最初缘由是移动用户的增长、低功耗设备和松散的网络。GraphQL最小化了须要网络传输的数据量，从而极大地改善了在这些条件下运行的应用程序。

2.各类不一样的前端框架和平台

前端框架和平台运行客户端应用程序的异构环境使得咱们在构建和维护一个符合全部需求的API变得困难，使用GraphQL每一个客户机均可以精确地访问它须要的数据。

3.在不一样前端框架，不一样平台下想要加快产品快速开发变的愈来愈难

持续部署已经成为许多公司的标准，快速的迭代和频繁的产品更新是必不可少的。对于REST api，服务器公开数据的方式经常须要修改，以知足客户端的特定需求和设计更改。这阻碍了快速开发实践和产品迭代。

       GraphQL的出现不只仅是针对开发人员的，Facebook在2012年开始在其native mobile apps中使用GraphQL。但有趣的是GraphQL大部分都是在web技术的背景下使用的，而且在native mobile 领域中只获得不多的支持。 Facebook第一次公开谈论GraphQL是在宣布开源计划后不久的2015年React峰会的时候。由于Facebook老是在React的背景下谈GraphQL，因此对于没有React经验的开发人员来讲，要理解GraphQL并非一种仅限于React使用的技术可能还须要一段时间。即使是在这样的背景下诞生的GraphQL依然是一个快速增加的社区 ,事实上GraphQL是一种技术，能够在客户端与API通讯的任何地方使用。有趣的是Netflix和Coursera等其余公司都在研究相似的想法以提升API的交互效率。Coursera设想了一种相似的技术，可让客户指定其数据需求，而Netflix甚至将其解决方案称为Falcor。在GraphQL被开源以后，Coursera彻底中止了他们在Falcor上的努力，并转到了GraphQL的学习上。目前已经有不少的公司在使用GraphQL（https://graphql.org/users/）。

GraphQL和RESTful的区别   

        前面提到GraphQL能够理解为基于RESTful的一种封装，目的在于构建使Client更加易用的服务，能够说GraphQL是更好的RESTful设计。在过去的十多年中，REST已经成为设计web api的标准(虽然只是一个模糊的标准)。它提供了一些很棒的想法，好比无状态服务器和结构化的资源访问。然而REST api表现得过于僵化，没法跟上访问它们的客户的快速变化的需求。 GraphQL的开发是为了应付更多的灵活性和效率，它解决了与REST api交互时开发人员所经历的许多缺点和低效之处。 为了说明在从API获取数据时REST和GraphQL之间的主要区别，让咱们考虑一个简单的示例场景：在blog应用程序中，应用程序须要显示特定用户的文章的标题。同一屏幕还显示该用户最后3个关注者的名称。REST和GraphQL如何解决这种状况?

 使用REST API来现实时，咱们一般能够经过访问屡次请求来收集数据。好比在这个示例中，咱们能够经过下面的三步来实现：

 1. 经过 /user/<id>获取初始用户数据

 2. 经过/user/<id>/posts 返回用户的全部帖子

 3. 请求/user/<id>/followers，返回每一个用户的关注者列表

调用关系以下图所示：

 

若是用GraphQL的话，咱们只须要一次请求就能够完成上述的需求

在GraphQL的世界里咱们不用多取数据，也不用担忧数据取少了，咱们只须要按需获取便可。

REST最多见的问题之一是API的返回数据过多或者过少，这是由于客户端下载数据的惟一方法是经过访问返回固定数据结构的endpoint，这就会致使咱们设计API很是困难，由于它既要可以为客户提供精确的数据需求，又须要知足不一样调用者的需求，这自己就是相互矛盾的。GraphQL的发明者Lee Byron提出了一个很重要的概念： “用图形来思考，而不是endpoint”

经过上述直观展现咱们能够得出一下几点：

1. 获取了许多多余的数据

一般状况下咱们在调用一个通用API接口时，客户端获取的信息比应用程序中实际须要的要多。例如UI须要显示一个用户列表，而实际上只须要使用他们的名字。在REST API中一般会调用 /user 这个endpoint，并接收一个带有用户数据的JSON数组。可是这个响应可能包含更多关于返回的用户的信息，例如他们的生日或地址，而这些信息对客户来讲是无用的，由于它只须要显示用户的名字。

2. 获取的数据少于Client所须要的数据

通常来讲数据获取不足意味着某个特定的endpoint 没有提供客户端须要的足够信息，客户端将须要额外的请求来获取它所须要的一切。这可能会升级到客户端须要首先获取列表信息，而后须要对单条数据添加一个额外的请求以获取其余所需的数据，例如考虑其余Client 也须要显示每一个用户的最后三个关注者，该API提供了额外的endpoint  /user/<userid>/followers，为了可以显示所需的信息，Client 必须向 /users endpoint 发出一个请求，而后点击/user/<user-id>/follwers endpoint 来获取单个用户的follwers信息。

3. 前端的快速产品迭代对API有很大的挑战

REST api的一个常见模式是根据您在应用程序内部的展示逻辑来构造endpoint，这很方便，由于它容许客户端经过访问相应的endpoint获取特定视图的全部所需信息。 这种方法的主要缺点是它不容许前端的快速迭代。对于UI所作的每个更改，如今都存在比之前更多(或更少)的数据的高风险。所以，须要对后端进行调整，以知足新的数据需求，这会下降生产力并显著下降将用户反馈集成到产品中的能力。 使用GraphQL这个问题就解决了。因为GraphQL的灵活性，无需在服务器上额外工做就能够在客户端上进行更改。因为客户端能够指定准确的数据需求，因此当前端的设计和数据需求发生变化时，并不须要后端API作出任何的修改就能够知足展示层的变化。

 4. Schema和类型系统的好处

GraphQL使用强大的Type System来定义API的功能。全部在API中公开的类型都是使用GraphQL schema Definition Language (SDL)在模式中编写的。该模式充当客户端和服务器之间的契约，以定义客户机如何访问数据。 一旦定义了模式，在前端和后端工做的团队就能够在没有进一步通讯的状况下完成工做，由于他们都知道经过网络发送的数据的确切结构。 前端团队能够经过mock所需的数据结构来轻松测试他们的应用程序。一旦后端API实现完成，就能够对客户端应用程序进行切换来调用实际的API获取数据，这也可使得咱们实现更好的客户端和服务端的分离。

写在最后

      咱们能够看出GraphQL的出现可使得咱们后端API具备更大的灵活性以及扩展性以知足不一样client对数据的须要，这大大丰富了API的数据提供的能力。