GraphQL初体验
What will we talk about?
之前总是看到GraphQL这个词(以下简称 GQL ),最近几天终于花时间了解一下 GQL ,最明显的一个结论是:它不是用来访问 DB 的,它是一种 API 设计方式。
GQL 可以说是一种规范/协议,不出意外会搜到 https://graphql.org
这个地址,这个网站只是对它的一些概念介绍,不包含什么框架与入门,所以上不了手。
个人感觉的优点
- 更加灵活
GQL 示例给人的第一个感觉就是:要什么字段就返回什么字段,返回结构与请求结构一模一样,不多不少,这也是各个 GQL 相关的网站常见的描述。此外,不像 Rest API 那样编写出一大堆 UR L,甚至多到有些URL名字很像,GQL 只有一个访问入口,它的不同查询/修改靠的是向这个路径传递不同的指令参数。 - 减少重复性工作
GQL中有个叫做resolver
的东西,它被用来描述如何获取字段对应的数据,一次查询就是对这些resolver
的链式组合。如果能把它设计好了,是可以减少重复性代码的,因为实现GQL规范的开源工具帮我们做了很多看不到的组合操作。 - 缓存
GQL客户端自带缓存,减少重复向服务端发起请求的次数。
个人感觉的缺点
- 复杂度增加
- 说白了就是没有 Rest API 简单直接,对于用惯了 Rest API 的开发人员来说,思维不是那么容易转变过来。
- 在编写 Rest API 的时候,前后端开发共同确认渲染所需数据,然后编写特定的接口,GQL 其实还是需要共同确认所需数据,后端编写
resolver
提供指令支持,所以交流这一步并没有简化。 - 相对于Rest API,GQL 就像是多包了一层。Rest API 在访问数据源之后,将查询得到的数据组合返回前端即可,而 GQL 则是访问数据源之后,把结果交给了
resolver
,然后由 GQL 组合再返回前端。回想一下 GQL 只有一个路径其他全靠指令,或许“多”的这一层就相当与 Controller 吧,或许应该叫做 API 。
- 有可能导致负优化
resolver
组织不好可能会导致访问DB的次数猛增。 - 错误处理
由于包了一层,导致距离 HTTP 思维方式较远,直接返回 200,具体什么错误需要到响应结果里查询,这一点需要看后端开发讲不讲武德,而 Rest API 甚至可以通过 HTTP 响应就可以更快确认问题所在。
可以上手GQL的开源工具
TS/JS:https://www.apollographql.com
这里有 course,可以顺利完成一个案例
Java:https://www.graphql-java.com/documentation/getting-started
本文作者:为何匆匆
本文链接:https://www.cnblogs.com/nyfblog/p/17703877.html
版权声明:本作品采用知识共享署名-非商业性使用-禁止演绎 2.5 中国大陆许可协议进行许可。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
· 上周热点回顾(2.17-2.23)