GraphQL前言

何谓GraphQL?

GraphQL本身不是一种框架更不是一种程式语言,笔者认为可以解读成一种有助于前端和后端工程师在开发时的规範.也可以想成一种可以替代前端使用fetch或是axios的工具.

我要怎么使用GraphQL?

前端

以前端来说,其实目前不论使用的是React,Vue或是angular都可以额外的安装package去完成这件事情,目前绝大多数人使用的为Apollo 笔者则是使用Meta的亲儿子Relay,不论你使用哪一种都可以,这些package的选择终究只是用法的差异,并不会影响到我们的结果

后端

以后端来说,不论是使用Node.js,Go或是Java等后端常见的程式语言,也都各自有适合的package去完成这件事情，笔者较熟悉的后端语言是Golang,所以选用了gqlgen,和前端同理,不论你选择了哪一种程式语言和package,都不会影响到我们最后的结果

未来的範例前后端分别使用React+Relay和Go+gqlgen.如果对React和Go都熟悉的读者应该可以很好理解,如果您不熟悉它们也没关係,并不会影响到您学习GraphQL的概念,只是语法上的不同而已

Why use GraphQL? 对我的人生有什么差异?

以下是笔者使用GraphQL一些时间后,列出与RESTful比较下的优点及一些小缺点.(仅代表笔者的想法)

优点(特色)

1.可以产出类似swagger的api文件(Playground),对于后端来说不用额外做一份api文件非常便利,对于前端来说也可以直接享有一份简易的api文件,如下图

2.避免Over-fetching(后面有更明确的介绍,先知道有这件事情即可):前端可以自己决定发送一次查询api后想要得到的value(当然后端要先定义好),如下图


可以看得出来,两只一样的api,只是把request body的内容抽换掉,就可以得到不同的结果,虽然看起来好像没什么影响,但如果今天query的资料量比较大时,前端可以决定想要收到的资料时,可以透过上述方式,解省传输的流量进一步减少前端loading的时间.

3.避免Under-fetching(后面有更明确的介绍,先知道有这件事情即可):前端可以合併多个查询及新增(更新,修改)并且组成一支api,发送给后端,可以避免多个api要多次发送api,让前端需要一直await的问题

可以看得出来同一只api里面包含了query patient和user的行为在里面，如果是原本的RESTful API，可能要打两支API或是在后端的行为上写一只把两个合併再一起的API，不论是哪一种作法都没有非常理想，前者在await上可能要额外花费许多时间(外部的检查，如:SSL及DNS)，后者的话会额外增加后端的複杂度，导致维护不便

我们也不要一昧的捧GraphQL,以下来看一些它的缺点

一些小缺点

在发生错误时,后端会回传200的http status code,并把错误内容包在response里面
为了能更明确的看出http status code，使用postman来测试(用Playground会得到一些的结果)
上述优点的第三点同时也是缺点,当一个query夹带了多个查询时,若有其中一个有错误,会导致整个api报错,让前端的画面看起来死的很凄惨不论前端是使用CRUD的哪一种api请求,一律都是发POST给后端,需要透过field name(下一篇会介绍)才能比较明确的知道该api的行为

以上皆为个人使用GraphQL后的一些心得,若有错误,还请不吝指教.接着会介绍GraphQL一些基本的做法还有如何在前后端实作

官方说GraphQL is the better REST

这边有一个官方的影片,因为影片有点久我就把我看到后觉得是重点的部分写下来
GraphQL官方影片-GraphQL is the better REST

GraphQL 的开发是为了满足在client和server端在发开时的需求,可以更有效率及灵活性他这边举了一个实务的情境有一个画面会显示使用者的个人资料,下面会呈现他曾经建立过的文章,最后还想显示最新的三个关注者,以REST API架构来说有三只api分别是 /user/{id},/user/{id}/posts和/user/{id}/follows

在第一步时我们往往会拿到一些不需要的资料,比如说地址或是电话,其实我们实际上只需要姓名就好了,再来不论是拿到建立过的文章或是最后三个关注者的资料都有相同的问题,其实也是前面有提到的Over-fetching,甚至最严重的是我们只需要三个关注者者,但实际上可以拉取了上万个我们用不到的关注者.


可以来看看GraphQL提出的做(解)法

Under-fetching-意思为一个endpoint的return无法满足实务上的需求,导致你需要叫x个endpoint的情境,会造成需要n+1-request problems个request的数量.虽然在在REST的架构下,后端可以新写一个endpoint满足实务上的需求,再让前端更改api,但实际的困难点是,每一次前端的UI有变动,除了后端要修改以外,前端也可能不只一个地方要修改,他们认为这对产品的迭代来说风险很高.
而GraphQL提出的解法为-都交给前端处理,后端不要去改动endpoint.Benefits of Schema & Types-所有的资料都是由Schema定义好的也有强型别的特性,前后端都很明确的知道可以用什么,什么可以用,或是资料应该是什么样子,跟REST比起来比较不会有滥(误)用的问题

点我开始学习GraphQL