作者appleboy46 (小恶魔)
看板Soft_Job
标题[心得] 为什麽要学 GraphQL?
时间Sat Jun 20 14:37:36 2020
来聊个简单的议题? 『为什麽要学 GraphQL?』
部落格好读版:
https://bit.ly/why-is-graphql
身为网站工程师，您不能不知道什麽是 GraphQL，这是一个前端跟後端沟通的 API
Query 语法，大幅改善了前後端的合作模式，这篇会跟大家介绍为什麽麽要学 GraphQL，
以及整理出三大 GraphQL 优势，让大家了解跟传统 Restful API 有什麽不同。当然不是
叫开发者舍弃 Restful API，而是根据专案的不同，来决定不同的技术 Stack。像是服务
跟服务之前您说要用 GraphQL，肯定被打枪，而是要用更轻量的 Restful API 或 GRPC。
好了，底下来说明三点 GraphQL 的优势。
影片:
https://www.youtube.com/watch?v=00NKSvAraLQ
01:36 一次连线拿回前端所需资料
04:07 根据不同画面拿不同栏位资料
06:06 即时 API 文件
1. 一次连线拿回前端所需资料
GraphQL 可以直接将 Query 语法写在一起送到後端，後端全部处理完成後再一次回给前
端，大幅降低 connection 次数。
2. 根据不同画面拿不同栏位资料
在 Restful API 世界里，後端会一次回传所有资料，不会管前端需不需要这栏位，也就
是前端没有权力决定该拿什麽栏位，这样会造成很多不必要的网路传输。Restful API
也可以根据不同画面回不同的栏位资讯，却造成後端很大的负担。这时候用 GraphQL 解
决了此问题，只要在 Query 语法内定义好要拿的资料即可。
3. 即时 API 文件
大家应该都知道文件没有一天是即时更新的，写 Restful API 要求後端也补上文件，简
直是难上加难，专案在赶的时候，谁还在管文件有没有到最新，这边就要推荐 GraphQL
了，因为只要程式码一动，开发者透过 Client 工具就可以即时知道现在的 API 文件。
--
Go 教学:
https://www.udemy.com/course/golang-fight/?couponCode=202006
Drone 教学:
https://www.udemy.com/course/devops-oneday/?couponCode=202006
Docker 教学:
https://www.udemy.com/course/docker-practice/?couponCode=202006
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.25.183.202 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1592635061.A.A78.html
1F：嘘 hegemon: 广告文又来了 06/20 14:59
2F：嘘 hegemon: 除了第一点以外其他两项REST也做得到 06/20 15:01
3F：推 lerdor: 针对第一点询问一下，这个成立的条件是在query的input相同 06/20 15:06
4F：→ lerdor: ？ 06/20 15:06
5F：推 sp063439: 推推 06/20 15:24
6F：推 shingatter: 同问第一题 06/20 15:41
7F：→ mystery7631: 怎麽没说graphQL文件和规则像大便 06/20 15:59
8F：→ jobintan: 当初因为玩Gatsby.JS，所以顺道学了GrapghQL。 06/20 16:26
9F：→ appleboy46: @lerdor 你可以把多个 query 语法写在一起 06/20 16:29
10F：→ appleboy46: blog 里面有范例，可以参考看看，就大概知道了 06/20 16:29
11F：→ appleboy46: @mystery7631 也不是没遇过雷 XD 06/20 16:30
12F：推 stupid0319: 还是传统md档最好用 06/20 16:39
13F：嘘 ray9592197: 不觉得graph那麽神，黑名单白名单订一订就订死你 06/20 16:57
14F：→ BlacksPig: 没办法做conn pool? 06/20 18:00
15F：推 s06yji3: 小弟不才，REST API有办法做conn pool 吗？ 06/20 18:05
17F：→ roccqqck: 这是宗教问题 06/20 18:35
18F：→ askaleroux: Swagger配Rest不行吗？ 06/20 19:55
19F：→ bheegrl: query语法送到後端啊...听起来就很雷的感觉 06/20 20:22
21F：→ bheegrl: 没用好就injection吃到饱 06/20 20:24
22F：→ x000032001: swagger跟graphql就相当於手动更新和自动更新 06/20 20:24
23F：→ appleboy46: Size Limiting, Query Whitelisting, Depth Limiting 06/20 20:34
24F：→ appleboy46: 这些都是需要自己再额外控制，增加 GraphQL 安全性 .. 06/20 20:34
25F：嘘 sharku: 为何不直接写後端 06/20 21:18
26F：→ sharku: swagger可以随code更新 难道你还手动维护 json or yml? 06/20 21:19
27F：→ xlf: 同意前面说的 实在很难做auth 06/20 21:55
28F：→ x000032001: 你还是要用codegen做 而graphql可以直接查schema 06/20 22:02
29F：→ x000032001: 真妙 推文都在守着RESTful 没人想讨论graph带来的可能 06/20 22:05
30F：推 s24601: 请问swagger怎麽随code更新 06/20 22:10
31F：→ sharku: 本文123点都不是graphql特有的优点 想推广也不是用这些 06/20 22:10
33F：→ zeroshine: 原 po 也没有说错啊 不知道大家在炮轰什麽 06/20 22:23
34F：推 a8989332: 文人相轻的日常 06/20 22:24
35F：→ zeroshine: graphql 真的让串 api 的复用变得相当的简单 06/20 22:25
36F：推 okd: 推一个 有内容可以讨论 不太明白在嘘什麽 06/20 22:25
37F：→ zeroshine: 甚至在 react apollo 的帮助下 整个 component 装下去 06/20 22:26
38F：→ zeroshine: 资料也会顺便拉好 06/20 22:26
39F：→ zeroshine: 後端工程师懒得帮你做资料转换 过滤 都可以让你在 gql 06/20 22:28
40F：→ zeroshine: 上做好 06/20 22:28
41F：推 zeroshine: 甚至可以用 directive 让这些逻辑应用在各个栏位上 06/20 22:30
42F：→ sharku: 像楼上几位提的几点还比较有推广到 06/20 22:54
43F：推 sojoasd: GraphQL 针对 query 来说，考量拿到什麽栏位，这倒是小 06/21 00:27
44F：→ sojoasd: 事，比较要注意的是栏位往下延伸时，有没有使用 dataload 06/21 00:27
45F：→ sojoasd: er 协助处理，否则db 查询会搞爆 server 06/21 00:27
46F：嘘 SIMD: 谁没文件在开发，先讨论好文件才开发吧 06/21 00:44
47F：→ jinmin88: swagger表示 我被当塑胶 06/21 01:36
48F：嘘 bibo9901: GraphQL就相当把後端结构完全泄漏给前端 06/21 05:48
50F：推 knives: graphql就是垃圾，就是个前端很爽，後端很干的概念 06/21 07:24
51F：推 b85040312: 後端为什麽很干 06/21 10:02
52F：推 mychiux413: 我用Go+GraphQL+Apollo(TS)，用了就回不去了 06/21 11:48
53F：→ appleboy46: @knives 什麽是後端很干的概念？ 06/21 11:48
54F：嘘 bibo9901: GraphQL和直接开SQL给前端有什麽本质上的差别? 06/21 15:00
55F：→ bibo9901: 完全失去封装的意义. 06/21 15:00
56F：→ lerdor: 我想询问的是第一点下，若要组装A跟B的query但是他们的inp 06/21 15:29
57F：→ lerdor: ut也分别是C跟D还可以成立吗？ 06/21 15:29
58F：→ neo5277: 就後端多一层就好了 06/21 15:31
59F：→ appleboy46: @lerdor 可以吧，所有的 Query 都由 Client 自行组装 06/21 15:36
60F：推 zeroshine: 例如说电商的商品资料在 mobile view 可能只需要 a b c 06/21 16:40
61F：→ zeroshine: 栏位 在 desktop web 下可能会需要 b c d e f 栏位 06/21 16:40
62F：→ zeroshine: graphql 就提供 quary language 让开发者可以 specify 06/21 16:41
63F：→ zeroshine: 所需要的资料栏位 而不会有 over fetch 的问题 06/21 16:42
64F：→ zeroshine: 也不需要让後端为各个不同的需求写不同的 end point 06/21 16:42
65F：推 zeroshine: 的确 restful 可以利用带参数来完成这种需求 但这就需 06/21 16:45
66F：→ zeroshine: 要工程师自己弄 也没有 graqhql 的 query 来的容易 06/21 16:46
67F：→ DendiQ: 不懂为啥说GraphQL跟直接开SQL给前端一样 06/21 16:47
68F：推 jaspreme206: 不懂GQL 的优势 还出来带风向 推文水准差矣 06/21 18:35
69F：→ paint: 最近有用 GraphQL 真心好用 06/21 20:48
70F：→ PretenderY: GraphQL最大的特点就是单一的Endpoint跟Type system 06/21 21:48
71F：→ dreamnook: 同样不懂哪里跟直接开SQL给前端相同 06/22 00:00
72F：推 marc47: 推用心整理 06/23 00:43
73F：推 vacuum: 大概是怕学新技术的老人看了很气 06/23 15:36
74F：推 lestibournes: 推，等等消化一下xD 06/24 22:20
75F：→ rodion: 刚看了下 可以说GraphQL非但没有破坏封装 反而是增加新的 06/29 10:58
76F：→ rodion: 封装 是说 GraphQL是对後端SQL(或其他DB)的封装 06/29 10:58
77F：→ rodion: 也因此 若应用於不适合的情景 可能会有过度封装/增加不必 06/29 10:59
78F：→ rodion: 要复杂度之虞 06/29 10:59
79F：→ rodion: 或许可以这样说 已经简单易懂够高效的RestAPI 改成GraphQL 06/29 11:01
80F：→ rodion: 是没啥意义的事情 甚至作茧自缚 06/29 11:01