来聊个简单的议题? ‘为什么要学 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 文件。

广告文又来了除了第一点以外其他两项REST也做得到

针对第一点询问一下，这个成立的条件是在query的input相同？

推推

同问第一题

怎么没说graphQL文件和规则像大便

当初因为玩Gatsby.JS，所以顺道学了GrapghQL。

@lerdor 你可以把多个 query 语法写在一起blog 里面有范例，可以参考看看，就大概知道了@mystery7631 也不是没遇过雷 XD

还是传统md档最好用

不觉得graph那么神，黑名单白名单订一订就订死你

没办法做conn pool?

小弟不才，REST API有办法做conn pool 吗？

这是宗教问题

Swagger配Rest不行吗？

query语法送到后端啊...听起来就很雷的感觉https://ithelp.ithome.com.tw/articles/10208008没用好就injection吃到饱

swagger跟graphql就相当于手动更新和自动更新

Size Limiting, Query Whitelisting, Depth Limiting这些都是需要自己再额外控制，增加 GraphQL 安全性 ..

为何不直接写后端swagger可以随code更新 难道你还手动维护 json or yml?

同意前面说的 实在很难做auth

你还是要用codegen做 而graphql可以直接查schema真妙 推文都在守着RESTful 没人想讨论graph带来的可能

请问swagger怎么随code更新

本文123点都不是graphql特有的优点 想推广也不是用这些

官网特色就说得够清楚了 https://graphql.org/原 po 也没有说错啊 不知道大家在砲轰什么

文人相轻的日常

graphql 真的让串 api 的复用变得相当的简单

推一个 有内容可以讨论 不太明白在嘘什么

甚至在 react apollo 的帮助下 整个 component 装下去资料也会顺便拉好后端工程师懒得帮你做资料转换 过滤 都可以让你在 gql上做好甚至可以用 directive 让这些逻辑应用在各个字段上

像楼上几位提的几点还比较有推广到

GraphQL 针对 query 来说，考量拿到什么字段，这倒是小事，比较要注意的是字段往下延伸时，有没有使用 dataloader 协助处理，否则db 查询会搞爆 server

谁没文件在开发，先讨论好文件才开发吧

swagger表示 我被当塑胶

GraphQL就相当把后端结构完全泄漏给前端

https://reurl.cc/z8GOQk 还是要看实际应用和需求

graphql就是垃圾，就是个前端很爽，后端很干的概念

后端为什么很干

我用Go+GraphQL+Apollo(TS)，用了就回不去了

@knives 什么是后端很干的概念？

GraphQL和直接开SQL给前端有什么本质上的差别?完全失去封装的意义.

我想询问的是第一点下，若要组装A跟B的query但是他们的input也分别是C跟D还可以成立吗？

就后端多一层就好了

@lerdor 可以吧，所有的 Query 都由 Client 自行组装

例如说电商的商品资料在 mobile view 可能只需要 a b c字段 在 desktop web 下可能会需要 b c d e f 字段graphql 就提供 quary language 让开发者可以 specify所需要的资料字段 而不会有 over fetch 的问题也不需要让后端为各个不同的需求写不同的 end point的确 restful 可以利用带参数来完成这种需求 但这就需要工程师自己弄 也没有 graqhql 的 query 来的容易

不懂为啥说GraphQL跟直接开SQL给前端一样

不懂GQL 的优势 还出来带风向 推文水准差矣

最近有用 GraphQL 真心好用

GraphQL最大的特点就是单一的Endpoint跟Type system

同样不懂哪里跟直接开SQL给前端相同

推用心整理

大概是怕学新技术的老人看了很气

推，等等消化一下xD

刚看了下 可以说GraphQL非但没有破坏封装 反而是增加新的封装 是说 GraphQL是对后端SQL(或其他DB)的封装也因此 若应用于不适合的情景 可能会有过度封装/增加不必要复杂度之虞或许可以这样说 已经简单易懂够高效的RestAPI 改成GraphQL是没啥意义的事情 甚至作茧自缚