从API迭代中解放!GraphQL的优缺点与团队价值
facebook推出的GraphQL,是一个特点非常鲜明的API查询语言。与SQL类似,GraphQL是一套规范,具体实现有很多框架。对前端而言,可以想使用SQL一样(比SQL简单且安全)可以直接获取自己所需要的数据,对于后端而言,节省了接口升级的开发成本,非常适用于快速迭代,或者多页面接口的业务。
本文会详细论述GraphQL的优缺点以及使用边界,以及对开发团队带来的价值。
1. 核心价值点介绍
1.1 核心特点
GraphQL的核心如下:
- 自由增减字段
- 一个请求可以保护多个资源
如图所示,左边的调用,只请求了hero的name字段。如果需要请求hero的height和mass字段,只需要简单添加就好。
从调用方的角度,可以非常方便且自由地增加查询字段。
从左边的调用图来看,请求了hero的friends成员,里面包含多个对象。如右图所示,可以很方便地聚合返回
1.2. 核心理念:所取即所得
所取即所得,展开来讲就是:『一次』请求,『只得』所需。
首先来看 『一次请求』代表的含义:
如图,一次请求的含义有2点:
- 单一入口:后端聚合请求,减少网络带宽
- 数据聚合:前端避免组装数据
其次来看『只得所需』的含义:
如图所示,请求方参数自由增减,GraphQL控制不重不漏。
2. 团队价值
2.1 开发价值——前端
对于前端开发人员,主要有以下3个价值:
- 避免多请求组装数据
- 避免过度获取数据
- 易于独立mock测试
举个例子来说明:
对于一个博客的用户主页, 只展示如下数据:
- 用户昵称
- 用户文章列表 (仅标题)
- 用户follower列表 (仅昵称)
传统的REST流程如下图,需要请求3次,得到不同的数据,还需要筛选组装成最终展示的数据。
而使用GraphQL,则只需要1次请求就可以实现这个功能:
对前端同学是不是非常友好?除此之外,因为只需要关注自己需要的数据,对于前端同学而言,非常方便mock,无需依赖后端开发提供接口。
2.2 开发价值——后端
对应后端开发同学而言,也有如下的价值:
- 减少针对性API设计
- 业务迭代时,修改方便
- 便捷文档(Code As Doc)
减少针对性API设计这点,主要体现在,比如针对『不同前端展示的字段不同』这类需求,传统做法是,用如下不同的URL来区分
- api/app
- api/miniapp
而使用GraphQL,后端不需要改变/新增接口,前端可以通过自定义请求参数来控制返回的数据。
同时,在业务迭代时,修改起来非常方便。
传统做法是使用如下方式做区分。
- api/app
- apiv2/app
如果使用GraphQL,后端无需变更协议,只需要在原来的接口增加字段就好,前端只需要请求新字段就好,不请求无效的字段就能实现接口更新。
GraphQL的开发形式,跟方便后端实现便捷的文档(Code As Doc),如图,只需要注释就可以描述此接口的功能:
在新业务快速开发时,文档总是落后版本。GraphQL实现了数据聚合,从而做到接口即文档。
2.3 业务价值
对于业务的价值如下:
- 两端接口定义更方便理解
- 前端扩张数据控制权
- 后端从接口适配中解放
GraphQL的灵活性,决定了前端无需与后台对齐接口,就可以开发。后台只需要在确定好的接口上提供数据就好,减少沟通成本。
基于上述的灵活性,前端对数据的控制权得到了增强,由原本的被动拼接,到GraphQL的主动定义,便于前端更理解业务,以及快速实现想法。
这种灵活性也是利好后端的,可以让后端不必频繁变更接口,也节省了Mock和粘合数据的时间,从而有更多时间关注底层涉及。
3. 缺点与挑战
- 业务重构困难
- 性能瓶颈
- 通用框架缺乏
把业务重构成GraphQL模式比较困难,因为要改造整个接口,所以不建议旧服务强行改造。
同时,因为全部通过 GraphQL Server 请求,也容易存在性能瓶颈。
由于GraphQL是单入口,现有的常用的组件框架不一定适配。如果团队要使用GraphQL的话,也需要为其配备专门的鉴权、缓存等组件框架,目前这方面生态只能说勉强够用,在内部使用比较方便,如果对外商用的话,可能需要重新设计一套标准。
4. 使用边界
评估业务是否需要使用GraphQL,首先最好有以下需求:
- 为团队赋能
- 多端展示
- 后端提供所有数据字段的CUDR
- 每个终端根据自己的需求请求对应的数据字段
- 业务迭代快
- GraphQL可以很好地解决Web端的版本迭代问题
- 对于移动端,GraphQL的版本控制不足
- 新旧业务不分离时,除非强迫客户端升级,否则只能无限期支持废弃字段
同时团队也要有如下条件:
- 足够的辅助框架建设水平
- 数据结构适配GraphQL
数据结构适配GraphQL主要是一下几点:
- 不支持直接传输文件、视频等数据
- 数据量过大导致的性能瓶颈
- 业务的数据需适配GraphQL的『图』,避免出现递归查询
- 数据库的设计
- 依赖服务的设计
- 可能存在的字段重复和冲突
参考
GraphQL party
面对极度复杂的前后端业务场景,使用 GraphQL 正确的姿势
其他
GitHub 为什么开放了一套 GraphQL 版本的 API?
相关文章
- apicloud团队协作添加模块,千月、七彩均可使用
- 阿常:开发团队如何提高产出质量
- 连续反转!DeepMind遭俄罗斯团队质疑:我们该如何证明神经网络懂物理世界?
- 如何打造一个真打团队
- 抖音API接口_抖音榜单数据api接口
- 李洪林团队发布首个快速高效的Markush结构图像识别系统
- 中科院 AI 团队最新研究发现,大模型可通过自我验证提高推理性能
- 阿斯利康团队用具有域适应性的可解释双线性注意网络改进了药物靶标预测
- 谁才是数字化转型时代具备真正实力的项目/团队?| InfoQ年终榜单颁奖典礼
- 浙大团队基于ML的抗菌肽筛选模型,可识别整个肽库空间发现新药
- 人类首次拍摄到电子固体画面,伯克利华人团队研究登上Nature
- .Net 7 团队把国内的龙芯确实当做一等公民和弃用的项目
- Linux窗口API:开启更灵活的开发革命(linux窗口api)
- NASA祝贺贝索斯团队顺利完成太空之旅 鼓励商业公司多参与太空飞行
- Oracle:是否具备API?(oracle有api吗)
- Linux API应用:开启新的编程之路(linux的api)
- Facebook AI团队让机器人行走适应各种环境和路面
- 19、如何兼顾团队分工的稳定性和灵活性?
- Oracle函数API:能够极大提升编程效率(oracle函数api)
- MySQL C API实现数据库应用程序(mysql的c语言api)
- Oracle实现轻松共享文件夹,提高团队协作效率(Oracle共享文件夹)
- 涅槃团队掌门人高雪峰:一个iOS漏洞值多少钱
- Konqueror过去一直是KDE桌面默认工具,因为它既是文件管理器也是网络浏览器。Konqueror有希望成为Linux桌面之王。KDE团队希望将Dolphin作为默认的文件管理器。但是Konqueror的浏览功能很强大,可以用默认的KHTML或WebKit安装且使用。
- 深入了解MongoDB中文API(mongodb中文api)
- MySQL C语言API应用注意事项(mysqlc语言api)
- API连接MySQL数据库实现快速灵活的数据存取(api连mysql数据库)
- 妙用API连接Oracle,轻松实现跨平台连接(api连oracle)
- API精准查询Oracle,轻松解决问题(Api查询oracle)
- 研究Oracle API接口,助推业务发展(oracle api接口)
- 九号公司上市后首次架构调整:成立四大机器人团队,要在未来扳回一局
- 如何打造一个平庸的流量团队
- 基于 Jenkins 构建的团队如何使用 Zadig 丝滑交付